[SOLVED] Alpine Linux KVM won't shutdown with Qemu Guest Agent

cheeseandcereal

New Member
Dec 18, 2018
6
2
1
40
I have Alpine Linux 3.8.1 virtual installed as a KVM virtual machine with the alpine linux Qemu Guest Agent package installed. I was able to get the guest agent working properly setting the serial port to /dev/vport2p1 (the UI would show IPs reported by the guest agent on the VM summary page), however with this guest agent enabled (and supposedly working), shutting down the VM no longer works.

I get the following error when trying to shut down the VM:
Code:
TASK ERROR: VM quit/powerdown failed - got timeout

If I disable the qemu guest agent in proxmox, shutdown via the ACPI signal works fine.

Is there anything I can do to further debug this issue? I would like to get shutdown working propely with the qemu guest agent enabled if at all possible.
 
Yeah, I actually found that thread, and that's what allowed me to get the guest agent working to the point where I could see the IPs in the UI summary page, indicating to me that the guest agent was (at least partially) working. I tried to link it in my original post but the forum doesn't let new members include links.

Either way I don't think it's a serial port problem or I presume I wouldn't be seeing the guest agent reported IPs on the summary page at all since the agent wouldn't be connected.

Not sure what else I could do to debug.
 
oh sorry, i missed that from your post

you could send the shutdown command manually with
Code:
qm guest cmd ID shutdown
and follow the logs inside the guest if you see anything noteworthy
 
These are the verbose logs of the guest agent inside the guest when running that from the proxmox host:

Code:
1545135516.580085: debug: read data, count: 100, data: {"arguments":{"id":8799501},"execute":"guest-sync-delimited"}{"arguments":{},"execute":"guest-ping"}
1545135516.580119: debug: process_event: called
1545135516.580133: debug: processing command
1545135516.580150: debug: sending data, count: 21
1545135516.580179: debug: process_event: called
1545135516.580185: debug: processing command
1545135516.580225: debug: sending data, count: 15
1545135516.580545: debug: received EOF
1545135516.681110: debug: read data, count: 104, data: {"arguments":{"id":8799502},"execute":"guest-sync-delimited"}{"arguments":{},"execute":"guest-shutdown"}
1545135516.681146: debug: process_event: called
1545135516.681159: debug: processing command
1545135516.681177: debug: sending data, count: 21
1545135516.681211: debug: process_event: called
1545135516.681217: debug: processing command
1545135516.681507: debug: sending data, count: 85
1545135516.681726: debug: received EOF

And here is the error that the proxmox host sees:
Code:
{
   "error" : {
      "class" : "GenericError",
      "desc" : "child process has failed to shutdown"
   }
}

I have a hunch that this might be due to the fact that the command to shutdown alpine linux is 'poweroff' (located at /sbin/poweroff as a symlink to busybox), and not 'shutdown', since all the rest of the guest-agent functionality seems to work, but I have no way to prove that at the moment, and the qemu guest agent installed was an alpine linux package, so I'm not sure...
 
Last edited:
AHA! My suspicions were confirmed.

I created a one-liner shell script at /sbin/shutdown and gave it execute permissions:
Code:
#!/bin/sh
/sbin/poweroff

And once I added this, the guest agent shutdown works. So it turns out it the guest agent itself was simply trying to execute the 'shutdown' command, even though this doesn't exist on alpine linux.

Problem solved.
 
  • Like
Reactions: Syrrys
mhmm yes... looking at the qemu source code, they hardcoded /sbin/shutdown
maybe you can open a bug on either qemu that they should not hardcode this, or maybe with alpine that they should patch the guest agent to call a different binary
 
Good day. Rookie here.
Running Alpine 3.15.0 VM inside Proxmox 7.1-11 - unlicensed. All updates applied on both thru date of this post.
Ran into the same problem described in this old thread with the current releases as noted.
Same solution worked perfectly.
Thank you.
 
I ran across this in the past found that installing udev and enabling that on boot allowed qemu guest agent to work as expected without additional scripts. Need to install from root account or run commands with sudo, which I also had to install separately.

Code:
apk add qemu-guest-agent udev
rc-update add udev boot
rc-update add udev-trigger boot
rc-update add udev-settle boot
rc-update add udev-postmount boot
rc-update add qemu-guest-agent
Followed by a reboot
 
Last edited:
  • Like
Reactions: si458 and Syrrys
I ran across this in the past found that installing udev and enabling that on boot allowed qemu guest agent to work as expected without additional scripts. Need to install from root account or run commands with sudo, which I also had to install separately.

Code:
apk add qemu-guest-agent udev
rc-update add udev boot
rc-update add udev-trigger boot
rc-update add udev-settle boot
rc-update add udev-postmount boot
rc-update add qemu-guest-agent
Followed by a reboot
Thanks for pointing this out, was struggling for quite some time trying to figure out the culprit.
This solution works like a champ! \o/
 
  • Like
Reactions: vesalius

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!