New Package Request: [qemu-guest-agent]

[Patricol]

Hello!

I'm improvising a format as per #736.

When running Flatcar as a guest/vm in Proxmox, there is no proper way to poweroff or restart Flatcar instances. The two usual options are qemu-guest-agent and acpid (#738), neither of which appear included in Flatcar. qemu-guest-agent provides quite a few more useful functions than just power management, so I'd see it as the higher-priority solution. Running it inside a container isn't really an option because of how directly it is intended to manage the Flatcar host.

This package will definitely improve the "Operate at scale / automation" core value, by adding a standard/upstream interface for managing Flatcar VMs.

Gentoo repo: https://github.com/gentoo/gentoo/tree/master/app-emulation/qemu-guest-agent

I believe it may only be necessary to include this package in the flatcar_production_qemu_image and flatcar_production_qemu_uefi_image images.

I may want to pursue acpid as well, especially because when I changed a setting to inform Proxmox that Flatcar instances don't support acpi, (in order to get Proxmox to try to use qemu-guest-agent for shutdown) I found that somehow breaks ignition's ability to find files specified with fw_cfg. (Please let me know if there's a more appropriate repo in which to open a separate issue for that.)

[Teeed]

This one is badly needed!

[tormath1]

Moving here the discussion initially made in this issue: https://github.com/flatcar-linux/Flatcar/issues/736

• Patricol: As a side note, is this the right place to request qemu-guest-agent? Or is there a more specific place for packages that are only needed in certain distribution images?
• pothos: An issue here for qemu-guest-agent is good, thanks (Edit: I think the agent isn't really OEM specific because QEMU gets used on different platforms and instead of the Flatcar OEM ID we could try to use the systemd virtualization detection)
• jepio: What other platforms would need the qemu-guest-agent, openstack? Do you suggest making it part of the /usr partition and then having a unit with ConditionVirtualization=qemu run it?
• pothos: Yes, the QEMU "OEM image" has no real customizations except the autologin setting and the fact that it is a qcow2 image. The generic image is quite good for usage with QEMU and is easy to customize through mounting it without any conversion, that's why I wouldn't want to make the QEMU "OEM image" more mandatory by introducing extra features that are otherwise not available.

[dipakparmar]

+1 for this would help a lot instead of manually installing.

[kjaleshire]

+1

[njegosrailic]

+1

[till]

Having it in the OpenStack image would be beneficial to us. :)

[jepio]

We hear you, this will soon be available across all images.

[till]

@jepio thank you, do I need to build a unit myself or will it start post install/update (to new OS)?

[jepio]

It should start automatically if you set hw_qemu_guest_agent=yes in your openstack instance config. You can testdrive one of the images from here: https://bincache.flatcar-linux.net/images/amd64/3396.0.0+qemu-guest-agent/.

[till]

@jepio so I guess that's for Glance. But can I make it work on existing infrastructure?

[jepio]

Disclaimer: I know nothing about openstack.

Might be possible following this guide https://www.thenoccave.com/2021/07/openstack-qemu-guest-tools-after-creation/ after the instance has updated (once the Flatcar release is available on our update servers).

[till]

Thanks, anyway! :) I'll have a look.

[till]

Ha... just read the link completely. Looks like I'll be editing the ☁️ soon.

For running instances, the gist of it is:

MariaDB > use nova
MariaDB [nova]> insert into instance_system_metadata (created_at, instance_uuid, `key`, value, deleted) VALUES (NOW(), '<InstanceID>', 'image_hw_qemu_guest_agent', 'yes', 0);
Query OK, 1 row affected (0.035 sec)

Then stop, start instance (reboot is not sufficient) and LBNL verifying the agent started: systemctl status qemu-guest-agent.service.