Proxmox VM: Added description for Proxmox GUI control of the DietPi VM

[StephanStS]

See also

• https://dietpi.com/forum/t/qemu-guest-agent-shutdown/5898/11
• https://blog.login.gmbh/dietpi-vm-qemu-agent-unter-proxmox/

[MichaIng]

Actually exactly this should be done automatically as part of the first run setup: https://github.com/MichaIng/DietPi/blob/06529cf/dietpi/dietpi-software#L14757-L14764

Is the condition probably not correct anymore on latest Proxmox VE?

ls -l /sys/class/virtio-ports/*/name
grep 'org.qemu.guest_agent.0' /sys/class/virtio-ports/*/name

[StephanStS]

I installed a new Proxmox DietPi VM with downloading the actual .xz file like described there: https://dietpi.com/docs/install/:

• After the firstrun of the VM:

  root@DietPi:/var/tmp/dietpi/logs# ls -l /sys/class/virtio-ports/*/name
  ls: cannot access '/sys/class/virtio-ports/*/name': No such file or directory
  root@DietPi:/var/tmp/dietpi/logs# grep 'org.qemu.guest_agent.0' /sys/class/virtio-ports/*/name
  grep: /sys/class/virtio-ports/*/name: No such file or directory
  root@DietPi:/var/tmp/dietpi/logs# 

  -> The virtio-ports directory is not present

• echo $G_HW_MODEL shows 20

• Control of DietPi VM is not possible through the Proxmox GUI (with or without enabled "QEMU Guest Agent" option):

  

• When running these commands (from the firstrun script) including a reboot

  G_AGI dbus
  G_EXEC systemctl unmask systemd-logind
  G_EXEC systemctl start systemd-logind
  G_AGI qemu-guest-agent
  reboot

  via cmd line it shows that dbus and qemu-guest-agent were not installed by default.

• After the execution of these 4 lines above, the controlling of the VM via the Proxmox GUI then works.

• The control of the VM also works with deactivated "QEMU Guest Agent" option in the DietPi VM settings.

[MichaIng]

ls: cannot access '/sys/class/virtio-ports/*/name': No such file or directory

Strange, I checked back on our Nextcloud server, and there it works:

# cat /sys/class/virtio-ports/vport2p1/name
org.qemu.guest_agent.0

Checking back the man page and service files of the package: https://manpages.debian.org/qemu-ga#OPTIONS

ls -l /dev/virtio-ports/org.qemu.guest_agent.0

This should actually exist, since it is the default and required for the QEMU guest agent service to even start. The sysfs entry might depend on the host Proxmox version or some config. It is at least used by one of the (K)VM tools: https://manpages.debian.org/virt-install#--channel

[MichaIng]

Fixed with: MichaIng/DietPi@cbbcd0c

[MichaIng]

@StephanStS
Let's continue here, it's difficult to find commit comments later:

Test results

Tested 4 combinations:

• Proxmox VM "Qemu Guest Agent" option enabled/disabled
• Qemu guest agent in VM installed/not installed

1. No option, no agent installed

• VM controllable via Proxmox GUI: No
• systemctl status qemu-guest-agent.service: Unit qemu-guest-agent.service could not be found.
• cat /sys/class/virtio-ports/vport1p1/name: No such file or directory
• ls -l /dev/virtio-ports/org.qemu.guest_agent.0: No such file or directory

2. With option, no agent installed

• VM controllable via Proxmox GUI: No
• systemctl status qemu-guest-agent.service: Unit qemu-guest-agent.service could not be found.
• cat /sys/class/virtio-ports/vport1p1/name: No such file or directory
• ls -l /dev/virtio-ports/org.qemu.guest_agent.0: No such file or directory

3. No option, agent installed

• VM controllable via Proxmox GUI: Yes
• systemctl status qemu-guest-agent.service: Active: inactive (dead)
• cat /sys/class/virtio-ports/vport1p1/name: No such file or directory
• ls -l /dev/virtio-ports/org.qemu.guest_agent.0: No such file or directory

4. With option, agent installed

• VM controllable via Proxmox GUI: Yes
• systemctl status qemu-guest-agent.service: Active: active (running)
• cat /sys/class/virtio-ports/vport1p1/name: org.qemu.guest_agent.0
• ls -l /dev/virtio-ports/org.qemu.guest_agent.0: lrwxrwxrwx 1 root root 11 Nov 24 22:09 /dev/virtio-ports/org.qemu.guest_agent.0 -> ../vport1p1

• Based on 2. vs 4., the virtio_console is not loaded until qemu-guest-agent is installed, right?
  • Could you verify it is loaded in 2. (via lsmod | grep virtio_console), then purge qemu-guest-agent, reboot and check again?
  • And do the two nodes/ports appear when you load the module manually (via modprobe virtio_console)?
  • I still do not understand how this can be. The package ships a udev rule, which triggers the qemu-guest-agent.service once/if the VirtIO port is detected. But there is no other config, especially none which would the module (and hence make the VirtIO port available) in the first place. I tested loading the module manually on our server, which is no QEMU VM, and there the ports do not appear.
  • So for our first boot, manually loading the module, then checking for the nodes, can be a way to detect whether it is a QEMU host. But I still want to understand why/how the ports appear automatically depending on whether qemu-guest-agent are installed.
• 3. means that there is an alternative way to control the VM from Proxmox, which does not depend on the QEMU quest agent. But probably it does not support all control commands or so?
  • Maybe @LOGIN-TB knows something about it?
  • In case of our server, it is ACPI with the button module. Can you check whether Proxmox control is still possible with this module unloaded (via modprobe -r button)? In case of our server, the acpi-support-base with acpid.service are however required, and also in VirtualBox, VMs do not react to ACPI commands just with the button driver loaded. Probably in case of Proxmox it is a different mechanism, hopefully revealed with lsmod.
  • Ah, is it actually a "soft"/graceful reboot/shutdown with the QEMU option disabled? Possible it is then doing just a hard reset, like pulling the power plug on a physical device? Could be seen on an open local console, whether there is output from systemd stopping services or whether it blanks/disappears immediately.

[StephanStS]

1.

* Based on 2. vs 4., the `virtio_console` is not loaded until `qemu-guest-agent` is installed, right?
  
  * Could you verify it is loaded in 2. (via `lsmod | grep virtio_console`), then purge `qemu-guest-agent`, reboot and check again?

I did this tests in 4., not in 2. (in 2. lsmod | grep virtio_console gives no output)

root@DietPi_4:~# lsmod | grep virtio_console
virtio_console         40960  1
virtio_ring            45056  5 virtio_console,virtio_balloon,virtio_scsi,virtio_pci,virtio_net
virtio                 20480  5 virtio_console,virtio_balloon,virtio_scsi,virtio_pci,virtio_net
root@DietPi_4:~#

Then apt purge qemu-guest-agent and reboot:

root@DietPi_4:~# lsmod | grep virtio_console
virtio_console         40960  0
virtio_ring            45056  5 virtio_console,virtio_balloon,virtio_scsi,virtio_pci,virtio_net
virtio                 20480  5 virtio_console,virtio_balloon,virtio_scsi,virtio_pci,virtio_net
root@DietPi_4:~#

2.

  * And do the two nodes/ports appear when you load the module manually (via `modprobe virtio_console`)?

Yes, they appear. I tested this in 2.:

root@DietPi_2:~# modprobe virtio_console
root@DietPi_2:~# lsmod | grep virtio_console
virtio_console         40960  0
virtio_ring            45056  5 virtio_console,virtio_balloon,virtio_scsi,virtio_pci,virtio_net
virtio                 20480  5 virtio_console,virtio_balloon,virtio_scsi,virtio_pci,virtio_net
root@DietPi_2:~#

Also in this state, 2. is not controllable via GUI.

3.

  * Ah, is it actually a "soft"/graceful reboot/shutdown with the QEMU option disabled? Possible it is then doing just a hard reset, like pulling the power plug on a physical device? Could be seen on an open local console, whether there is output from systemd stopping services or whether it blanks/disappears immediately.

It reacts like a manual poweroff and not a reset/power cycle. The console output shows this.

[MichaIng]

Even more confusing: Installing qemu-guest-agent makes the module load automatically, but after purging it again, it still does load? Is the module still loaded after you apt autopurge all dependencies of qemu-guest-agent?

Yes, they appear. I tested this in 2.:

I mean the two device nodes:

ls -l /sys/class/virtio-ports/vport1p1/name /dev/virtio-ports/org.qemu.guest_agent.0

It reacts like a manual poweroff and not a reset/power cycle. The console output shows this.

Can you paste the output of lsmod? I hope it reveals another driver used to enable communication between host and guest.

[StephanStS]

1.

Tested this in 2.:

root@DietPi_2:~# ls -l /sys/class/virtio-ports/vport1p1/name /dev/virtio-ports/org.qemu.guest_agent.0
lrwxrwxrwx 1 root root   11 Nov 26 15:44 /dev/virtio-ports/org.qemu.guest_agent.0 -> ../vport1p1
-r--r--r-- 1 root root 4096 Nov 26 15:44 /sys/class/virtio-ports/vport1p1/name
root@DietPi_2:~# apt autopurge
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following packages will be REMOVED:
  libnuma1* liburing2*
0 upgraded, 0 newly installed, 2 to remove and 0 not upgraded.
After this operation, 118 kB disk space will be freed.
Do you want to continue? [Y/n]
(Reading database ... 18288 files and directories currently installed.)
Removing libnuma1:amd64 (2.0.16-1) ...
Removing liburing2:amd64 (2.3-3) ...
Processing triggers for libc-bin (2.36-9+deb12u3) ...
root@DietPi_2:~# ls -l /sys/class/virtio-ports/vport1p1/name /dev/virtio-ports/org.qemu.guest_agent.0
lrwxrwxrwx 1 root root   11 Nov 26 15:44 /dev/virtio-ports/org.qemu.guest_agent.0 -> ../vport1p1
-r--r--r-- 1 root root 4096 Nov 26 15:44 /sys/class/virtio-ports/vport1p1/name
root@DietPi_2:~#

2.

It reacts like a manual poweroff and not a reset/power cycle. The console output shows this.

Can you paste the output of lsmod? I hope it reveals another driver used to enable communication between host and guest.

root@DietPi_2:~# lsmod
Module                  Size  Used by
hid_generic            16384  0
usbhid                 65536  0
hid                   155648  2 usbhid,hid_generic
sha512_ssse3           49152  0
sha512_generic         16384  1 sha512_ssse3
sr_mod                 28672  0
cdrom                  81920  1 sr_mod
bochs                  16384  0
joydev                 28672  0
drm_vram_helper        20480  1 bochs
uhci_hcd               57344  0
drm_ttm_helper         16384  2 bochs,drm_vram_helper
aesni_intel           393216  0
virtio_net             73728  0
ehci_hcd              102400  0
ttm                    94208  2 drm_vram_helper,drm_ttm_helper
ata_generic            16384  0
net_failover           24576  1 virtio_net
crypto_simd            16384  1 aesni_intel
psmouse               184320  0
cryptd                 28672  1 crypto_simd
usbcore               348160  3 usbhid,ehci_hcd,uhci_hcd
failover               16384  1 net_failover
pcspkr                 16384  0
drm_kms_helper        204800  4 bochs,drm_vram_helper
virtio_console         40960  0
usb_common             16384  3 usbcore,ehci_hcd,uhci_hcd
i2c_piix4              28672  0
virtio_balloon         24576  0
ata_piix               45056  0
floppy                 86016  0
button                 24576  0
evdev                  28672  2
serio_raw              20480  0
sg                     40960  0
fuse                  176128  1
drm                   614400  6 drm_kms_helper,bochs,drm_vram_helper,drm_ttm_helper,ttm
loop                   32768  0
efi_pstore             16384  0
dm_mod                184320  0
configfs               57344  1
qemu_fw_cfg            20480  0
ip_tables              36864  0
x_tables               61440  1 ip_tables
autofs4                53248  2
ext4                  983040  1
crc16                  16384  1 ext4
mbcache                16384  1 ext4
jbd2                  167936  1 ext4
crc32c_generic         16384  0
crc32c_intel           24576  2
BusLogic               32768  0
virtio_pci             24576  0
virtio_pci_legacy_dev    16384  1 virtio_pci
virtio_pci_modern_dev    20480  1 virtio_pci
virtio_scsi            28672  1
virtio_ring            45056  5 virtio_console,virtio_balloon,virtio_scsi,virtio_pci,virtio_net
virtio                 20480  5 virtio_console,virtio_balloon,virtio_scsi,virtio_pci,virtio_net
scsi_transport_fc      90112  0
vmw_pvscsi             32768  0
sd_mod                 65536  1
t10_pi                 16384  1 sd_mod
crc64_rocksoft         20480  1 t10_pi
crc_t10dif             20480  1 t10_pi
crct10dif_generic      16384  1
crc64                  20480  1 crc64_rocksoft
crct10dif_common       16384  2 crct10dif_generic,crc_t10dif
ahci                   49152  0
libahci                49152  1 ahci
libata                401408  4 ata_piix,libahci,ahci,ata_generic
scsi_mod              286720  8 virtio_scsi,vmw_pvscsi,sd_mod,BusLogic,scsi_transport_fc,libata,sg,sr_mod
scsi_common            16384  4 scsi_mod,libata,sg,sr_mod
root@DietPi_2:~#

[MichaIng]

In case of the first test, is the module still loaded, respectively are the nodes still present after reboot?

I did misread 3., as the guest agent is installed there as well. virtio_console is there, even that it is (currently) unused. So it really seems to be the guest agent installation (respectively one of its dependencies) which triggers the module to be loaded, not the enabled setting in Proxmox GUI. And it seems that the module needs to be loaded for the VM to react to Proxmox commands, regardless whether the guest agent is running or not, and whether the nodes are available or not.

To me it looks like there are two ways:

1. On a fresh DietPi Proxmox VM with QEMU GA option disabled, run modprobe virtio_console to make the VM react to Proxmox shutdown/reboot commands with a so far unknown communication node, but still using virtio_console. This could be made permanent via echo virtio_console > /etc/modules-load.d/proxmox,conf.
   • Would be interesting to know whether this works regardless whether the QEMU option is enabled or not.
   • Would be also interesting whether this has any downsides or upsides compared to using the QEMU GA option. Probably something to consult the Proxmox docs. If there are no downsides, and it works with and without QEMU GA option, we could just ship our images with above config, to assure the kernel module is loaded OOTB, then this whole topic is solved an no manual or automated step would be required on first boot.
2. On a fresh DietPi Proxmox VM with QEMU GA option enabled, install qemu-quest-agent. Our end, we can run modprobe virtio_console and then check for the existence of the nodes, to know whether the QEMU option is enabled, and then install the quest agent based on this.
   • Just to assure this really works, and there is no delay between module load and nodes:

     modprobe virtio_console && ls -l /dev/virtio-ports/org.qemu.guest_agent.0

[StephanStS]

Test A

1. On a fresh DietPi Proxmox VM with QEMU GA option disabled, run modprobe virtio_console to make the VM react to Proxmox shutdown/reboot commands with a so far unknown communication node, but still using virtio_console. This could be made permanent via echo virtio_console > /etc/modules-load.d/proxmox,conf.

Test on "QEMU GA disabled":

modprobe virtio_console
echo virtio_console > /etc/modules-load.d/proxmox.conf
reboot

Then, after the reboot:

• Check lsmod:

root@DietPi:~# lsmod | grep virtio_console
virtio_console         40960  0
virtio_ring            45056  5 virtio_console,virtio_balloon,virtio_scsi,virtio_pci,virtio_net
virtio                 20480  5 virtio_console,virtio_balloon,virtio_scsi,virtio_pci,virtio_net

• Check VM control via Proxmox GUI: Does not work

Test B

Same as Test A, but with "QEMU GA enabled":
Directly after booting:

• Check lsmod:

root@DietPi:~# lsmod | grep virtio_console
virtio_console         40960  0
virtio_ring            45056  5 virtio_console,virtio_balloon,virtio_scsi,virtio_pci,virtio_net
virtio                 20480  5 virtio_console,virtio_balloon,virtio_scsi,virtio_pci,virtio_net

So, a modprobe virtio_console is not needed.

• Check VM control via Proxmox GUI: Does not work

Test C

2. On a fresh DietPi Proxmox VM with QEMU GA option enabled, install qemu-quest-agent. Our end, we can run modprobe virtio_console and then check for the existence of the nodes, to know whether the QEMU option is enabled, and then install the quest agent based on this.

   • Just to assure this really works, and there is no delay between module load and nodes:

     modprobe virtio_console && ls -l /dev/virtio-ports/org.qemu.guest_agent.0

Directly after booting:

root@DietPi:~# apt install qemu-guest-agent
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
qemu-guest-agent is already the newest version (1:7.2+dfsg-7+deb12u2).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
root@DietPi:~#

• Check VM control via Proxmox GUI: Does not work

root@DietPi:~# modprobe virtio_console && ls -l /dev/virtio-ports/org.qemu.guest_agent.0
lrwxrwxrwx 1 root root 11 Nov 29 19:07 /dev/virtio-ports/org.qemu.guest_agent.0 -> ../vport1p1
root@DietPi:~#

Also after a reboot:

• Check VM control via Proxmox GUI: Does not work

If I then execute apt install dbus nothing changes.

If I execute:

systemctl unmask systemd-logind
apt reinstall dbus
systemctl start systemd-logind

• Check VM control via Proxmox GUI: Does work

Test D

• Fresh install, option enabled

If I execute:

systemctl unmask systemd-logind
apt install dbus
systemctl start systemd-logind

• Check VM control via Proxmox GUI: Does not work

After a reboot

• Check VM control via Proxmox GUI: Does work

Test E

• Fresh install, option enabled

If I execute:

G_AGI dbus
G_EXEC systemctl unmask systemd-logind
G_EXEC systemctl start systemd-logind

• Check VM control via Proxmox GUI: Does not work

After a reboot

• Check VM control via Proxmox GUI: Does work

Test F

• Fresh install, option disabled

G_AGI dbus
G_EXEC systemctl unmask systemd-logind
G_EXEC systemctl start systemd-logind

• Check VM control via Proxmox GUI: Does work

-> Works without reboot and without apt install qemu-guest-agent

[MichaIng]

So you mean qemu-guest-agent does neither help nor is it needed to make GUI reboot/shutdown work, despite the option enabled in Proxmox, but the only required thing is logind + for somehow strange reasons a reboot?

These were all Bookworm systems, right (as on Bullseye, logind is required for qemu-guest-agent to run)?

I lost the overview, but the results seem contradicting. Probably it takes some time for the nodes to appear, or another trigger or we missed another difference between the tested systems. Let's talk tomorrow about it.

[StephanStS]

So you mean qemu-guest-agent does neither help nor is it needed to make GUI reboot/shutdown work, despite the option enabled in Proxmox, but the only required thing is logind + for somehow strange reasons a reboot?

These were all Bookworm systems, right (as on Bullseye, logind is required for qemu-guest-agent to run)?

I lost the overview, but the results seem contradicting. Probably it takes some time for the nodes to appear, or another trigger or we missed another difference between the tested systems. Let's talk tomorrow about it.

See also Test F result added above: Works without QEMU GA option, without qemu-guest-agent installation and without reboot.
Seems that the initial dietpi-software run does not install all as needed.

[MichaIng]

Seems that the initial dietpi-software run does not install all as needed.

It does not enable or install anything currently, hence this PR and tests 😉. Currently I fail to see which difference the QGA option in Proxmox does at all, but only dbus and/or logind make the difference. At least modprobe virtio_console && ls -l /dev/virtio-ports/org.qemu.guest_agent.0 seems to work to detect a QEMU VM with the option enabled, but it is pointless if the option itself is pointless.

[StephanStS]

@MichaIng: Did some text modifications in regard of your dietpi-software first-run changes.

[MichaIng]

Shall we keep it simple and just keep the info for v8.25 and above (and hence merge it after release + image updates)?

Btw:

• The QEMU option can now be enabled as well, and the QEMU guest agent will be automatically installed in this case. Although not 100% sure if we tested this after I added the modprobe command during our meeting? But I think we did.
• If firstrun setup finished already (either v8.24 image, or QEMU option was enabled after firstrun finished), with v8.25 one can run:

  /boot/dietpi/func/dietpi-set_hardware qemu-guest-agent enable
  # or shorter
  /boot/dietpi/func/dietpi-set_hardware qga 1

  This includes now the modprobe to assure the module is loaded and hence the QEMU node detected. And it installs dbus and unmasks systemd-logind, if this was not done before. So this one command could replace the current v8.24 block, once v8.25 was released.