Linux - Virtualization and CloudThis forum is for the discussion of all topics relating to Linux Virtualization and Linux Cloud platforms. Xen, KVM, OpenVZ, VirtualBox, VMware, Linux-VServer and all other Linux Virtualization platforms are welcome. OpenStack, CloudStack, ownCloud, Cloud Foundry, Eucalyptus, Nimbus, OpenNebula and all other Linux Cloud platforms are welcome. Note that questions relating solely to non-Linux OS's should be asked in the General forum.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
It might be more of the way you pose the question.
If you shutdown qemu it would not allow the guest os time to shutdown properly. Depending on the VM you may have choices as to how that process happens also. Some allow you to choose. One choice may be to save state. One next start it resumes from where you left it. One one choice it is a hard power down. Other choices may exist too.
If you shutdown the guest from the normal OS shutdown then the end would be that qemu shuts down.
* Assume that I do not have control over Guest OS, but still I would like to signal the OS to
shutdown gracefully. Via QEMU-Monitor, I am able to issue a shutdown command to the VM.
I would like to understand the execution steps in this case.
Then I think this is the correct answer. If you shutdown qemu it would not allow the guest os time to shutdown properly. UNLESS this works but you'd have to test it.
"system_powerdown
This has an effect similar to the physical power button on a modern PC. The VM will get an ACPI shutdown request and usually shutdown cleanly."
If you had access to the qemu monitor you may be able to save or stop or take a snapshot. See this page for the commands in monitor that may help. (assumes some level and compile and arch too)
in very simple terms, QEMU sends the VM an ACPI shutdown command, same as what would happen when you click the power button on a physical machine. If that fails, you can issue the "destroy" command which will act as if you've pulled the plug on the VM
---------- Post added 06-04-11 at 11:16 AM ----------
note that for this to work, the VM has to be running with ACPI enabled and using an ACPI enabled HAL
in very simple terms, QEMU sends the VM an ACPI shutdown command, same as what would happen when you click the power button on a physical machine. If that fails, you can issue the "destroy" command which will act as if you've pulled the plug on the VM
---------- Post added 06-04-11 at 11:16 AM ----------
note that for this to work, the VM has to be running with ACPI enabled and using an ACPI enabled HAL
Is there a signal that could be sent in lieu of a command, to QEMU's process, so that rc scripts shutting the host down can get QEMU to send that power button ACPI signal to the guest OS?
system_powerdown is the command to send to the VM's monitor of course, it has already been mentioned.
But for host system rc scripts, a signal is the usual means. Entering a command line is not readily done, as a script would have to hunt down the appropriate pty and take over. Normally rc scripts send a SIGTERM signal to processes to have them do a graceful end. QEMU just exits when it gets SIGTERM. Maybe some other signal will make it do the guest ACPI thing?
you have it completely wrong.
Every VM running with QEMU maintains a socket, through which the host communicates with the QEMU process.
This socket is called qemu monitor, and can be accessed. When you access it, you do not access the VM itself, but the actual process that keeps it running, so when you issue "system_powerdown" to that process, it will emulate an ACPI shutdown in the guest space.
If the VM itself supports ACPI, it will detect the ACPI shutdown request, and that will trigger the normal init scripts and the rest of the typical sequence.
you have it completely wrong.
Every VM running with QEMU maintains a socket, through which the host communicates with the QEMU process.
I don't see anything in the documentation where a socket can be accessed to send the emulator a monitor command. Doing "lsof" on a running qemu emulator shows 2 pipes and 2 unit domain sockets without names (hence, there is no target to make a connection to).
Quote:
Originally Posted by dyasny
This socket is called qemu monitor, and can be accessed. When you access it, you do not access the VM itself, but the actual process that keeps it running, so when you issue "system_powerdown" to that process, it will emulate an ACPI shutdown in the guest space.
There is a monitor already in the manual command line session. Is that what you are referring to? That's where I can type in "system_powerdown" and watch the guest OS either do the right thing or not (depending on whose opinion of the right thing we are referring to).
There is a monitor already in the manual command line session. Is that what you are referring to? That's where I can type in "system_powerdown" and watch the guest OS either do the right thing or not (depending on whose opinion of the right thing we are referring to).
that's the monitor exactly. what happens when it doesn't work for you?
that's the monitor exactly. what happens when it doesn't work for you?
Desktop systems put up a prompt asking to shutdown, just like selecting the shutdown menu item. There's usually a 60 second wait. That means I'd have to be sure the host has an extra 60 seconds shutdown process time before doing an aggressive process kill.
Server systems work in some cases (Slackware) and not at all in other (Ubuntu server just stays up).
The real issue is getting that signal to the QEMU process at the time init is sending SIGTERM to other processes. If QEMU were to handle SIGTERM by doing the power button emulation, the issue would be gone. If it could make made to handle it on another signal like SIGHUP, that would be easy to work around. But, getting init to start a script that will hunt down the QEMU monitor sockets to feed in the command line, I have no clue where to start with that.
I have a script, which is called from rc.local_shutdown, on my slackware host which will issue a ACPI shutdown command to all running guests, then wait for 60 secs for them to cleanly shutdown.
If all the guests cleanly shutdown before the timeout, the script will exit and the host will continue shutting down, if not, it will force shutdown to all running guests and the host will continue shutting down.
#!/bin/bash
# number of seconds to wait for VMs to shutdown, before killing them
MAX_TIMEOUT=60
RUNNING_VM_LIST=$(/usr/sbin/virsh list|grep running|cut -d " " -f 4-4)
for RUNNING_VM in $RUNNING_VM_LIST; do
/usr/sbin/virsh shutdown $RUNNING_VM
done
TIMEOUT_COUNTER=0
while true; do
RUNNING_VM_LIST=$(/usr/sbin/virsh list|grep running|cut -d " " -f 4-4)
if [ -z "$RUNNING_VM_LIST" ]; then
exit 0
else
if [ $TIMEOUT_COUNTER -lt $MAX_TIMEOUT ]; then
sleep 1
TIMEOUT_COUNTER=$[$TIMEOUT_COUNTER+1]
else
for RUNNING_VM in $RUNNING_VM_LIST; do
/usr/sbin/virsh destroy RUNNING_VM
done
fi
fi
done
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.