QEMU Guest Agent fails to activate on Ubuntu 24.04

[cal-andrew]

Following the instructions added in #151 to configure the QEMU Guest Agent for a libvirt-based virtual machine, neither enabling nor starting qemu-guest-agent.service works.

This is the default contents of qemu-guest-agent.service in Ubuntu:

[Unit]
Description=QEMU Guest Agent
BindsTo=dev-virtio\x2dports-org.qemu.guest_agent.0.device
After=dev-virtio\x2dports-org.qemu.guest_agent.0.device

[Service]
ExecStart=-/usr/bin/qemu-ga
Restart=always
RestartSec=0

[Install]

And the diff from upstream:

3c3
< BindTo=dev-virtio\x2dports-org.qemu.guest_agent.0.device
---
> BindsTo=dev-virtio\x2dports-org.qemu.guest_agent.0.device
7c7
< ExecStart=-/usr/bin/qemu-ga
---
> ExecStart=-/usr/sbin/qemu-ga

However, changing BindsTo to BindTo and running systemctl daemon-reload did not solve the problem. Any ideas?

[KernelGhost]

Installing QEMU Guest Agent in Ubuntu/Debian should be fairly straightforward.

Are you receiving any error messages? What does sudo systemctl status qemu-guest-agent return?

If it is of any assistance, the result of cat /usr/lib/systemd/system/qemu-guest-agent.service on Fedora 40:

[Unit]
Description=QEMU Guest Agent
BindsTo=dev-virtio\x2dports-org.qemu.guest_agent.0.device
After=dev-virtio\x2dports-org.qemu.guest_agent.0.device
IgnoreOnIsolate=True

[Service]
UMask=0077
EnvironmentFile=/etc/sysconfig/qemu-ga
ExecStart=/usr/bin/qemu-ga \
  --method=virtio-serial \
  --path=/dev/virtio-ports/org.qemu.guest_agent.0 \
  --blacklist=${BLACKLIST_RPC} \
  -F${FSFREEZE_HOOK_PATHNAME}
Restart=always
RestartSec=0

[Install]
WantedBy=dev-virtio\x2dports-org.qemu.guest_agent.0.device

[cal-andrew]

Thanks for your help.

Running sudo systemctl start qemu-guest-agent takes a while and then gives me the error: A dependency job for qemu-guest-agent.service failed. See 'journalctl -xe' for details.

Running journalctl -xe I see:

dev-virtio\x2dports-org.qemu.guest_agent.0.device: Job dev-virtio\x2dports-org.qemu.guest_agent.0.device/start timed out.
Timed out waiting for device dev-virtio\x2dports-org.qemu.guest_agent.0.device - /dev/virtio-ports/org.qemu.guest_agent.0.

Actually this problem is popping up all over the internet, but I haven't found a solution yet.

[LDprg]

@cal-andrew can you post your system info. Maybe it is something distro or hardware dependent.

[cal-andrew]

I am using a Thinkpad E16 Gen 1 (AMD Ryzen 7 7730U) with a Linux 6.8 kernel.

[KernelGhost]

@cal-andrew The error message suggests that the qemu-guest-agent service is failing to start because it cannot locate the device /dev/virtio-ports/org.qemu.guest_agent.0. This likely indicates that the hypervisor is not providing the necessary virtio device to the Windows guest.

Could you please provide us with your Windows VM XML using virsh dumpxml RDPWindows?

[dannycarbonero]

I'm having a very similar issue on Ubuntu 20.04, how can I start debugging this?

[juniornff]

@cal-andrew The error message suggests that the qemu-guest-agent service is failing to start because it cannot locate the device /dev/virtio-ports/org.qemu.guest_agent.0. This likely indicates that the hypervisor is not providing the necessary virtio device to the Windows guest.

Could you please provide us with your Windows VM XML using virsh dumpxml RDPWindows?

In my case i got this: virsh dumpxml RDPWindows.txt

I even added the line WantedBy=dev-virtio\x2dports-org.qemu.guest_agent.0.device to see if that would get the service started, but it didn't work.

Im setting up the VM with libvirt. Im stock in that step.

Edit:

After a lot of back and foward with ChatGPT i did 2 things:

I add

[Install]
WantedBy=multi-user.target

to the .service file. The service can be enable now, but can't start the sevice.

Whit sudo systemctl list-dependencies qemu-guest-agent.service i got this list:

qemu-guest-agent.service
○ ├─dev-virtio\x2dports-org.qemu.guest_agent.0.device
● ├─system.slice
● └─sysinit.target
●   ├─apparmor.service
●   ├─blk-availability.service
●   ├─dev-hugepages.mount
●   ├─dev-mqueue.mount
●   ├─keyboard-setup.service
●   ├─kmod-static-nodes.service
●   ├─lvm2-lvmpolld.socket
●   ├─lvm2-monitor.service
○   ├─mdadm-shutdown.service
●   ├─plymouth-read-write.service
●   ├─plymouth-start.service
●   ├─proc-sys-fs-binfmt_misc.automount
●   ├─sys-fs-fuse-connections.mount
●   ├─sys-kernel-config.mount
●   ├─sys-kernel-debug.mount
●   ├─sys-kernel-tracing.mount
○   ├─systemd-ask-password-console.path
●   ├─systemd-binfmt.service
○   ├─systemd-firstboot.service
●   ├─systemd-journal-flush.service
●   ├─systemd-journald.service
○   ├─systemd-machine-id-commit.service
●   ├─systemd-modules-load.service
○   ├─systemd-pcrphase-sysinit.service
○   ├─systemd-pcrphase.service
○   ├─systemd-pstore.service
●   ├─systemd-random-seed.service

And the last thing chatgpt make me notice was that the /dev/virtio-ports/ folder doesn't exist. According to chatgpt, when starting the VM it should create a folder (and I don't know what files I should put there)

[Endie-157]

Same issue on Arch, with the same errors showing up in journalctl -xe as the original report. Starting the service just makes it stuck with ctrl+c being the only exit. Enabling the service gives the message :

The unit files have no installation config (WantedBy=, RequiredBy=, UpheldBy=,
Also=, or Alias= settings in the [Install] section, and DefaultInstance= for
template units). This means they are not meant to be enabled or disabled using systemctl.

Possible reasons for having these kinds of units are:
• A unit may be statically enabled by being symlinked from another unit's
  .wants/, .requires/, or .upholds/ directory.
• A unit's purpose may be to act as a helper for some other unit which has
  a requirement dependency on it.
• A unit may be started when needed via activation (socket, path, timer,
  D-Bus, udev, scripted systemctl call, ...).
• In case of template units, the unit is meant to be enabled with some
  instance name specified.

If it's not distro dependent it's possibly an issue with qemu-guest-agent upstream.