How does QEMU shuts down a Guest OS.

alphy · 06-03-2011, 03:53 PM

Hi,

I am trying to understand the internals of the shutdown procedure in a virtual machine.

The aim is to understand:
1) How does the QEMU process, shuts down the Guest OS gracefully.

Any pointers in this regard would be useful

Thanks,
Alphonse

TobiSGD · 06-03-2011, 04:07 PM

It doesn't. The OS shuts down itself, like it would do on a physical machine.

jefro · 06-03-2011, 04:37 PM

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.

alphy · 06-03-2011, 07:17 PM

Ok. Let me rephrase my question to be specific.

* 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.

Thanks for the information.

-Alphonse

jefro · 06-03-2011, 08:17 PM

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)

http://en.wikibooks.org/wiki/QEMU/Monitor

In no case that I know of can qemu send a shutdown command to the client os. ssh, vnc, telnet or such is used if acpi issue.

dyasny · 06-04-2011, 06:15 AM

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

Skaperen · 06-06-2011, 10:22 AM

Quote:

Originally Posted by dyasny

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?

dyasny · 06-06-2011, 12:14 PM

system_powerdown is the command to send to the VM's monitor of course, it has already been mentioned.

Skaperen · 06-06-2011, 01:11 PM

Quote:

Originally Posted by dyasny

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?

dyasny · 06-07-2011, 02:01 AM

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.

Skaperen · 06-07-2011, 02:00 PM

Quote:

Originally Posted by dyasny

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).

jefro · 06-07-2011, 03:02 PM

I think it would boil down to a proper test on a test platform to be sure. ACPI has failed me before on qemu.

dyasny · 06-08-2011, 05:39 AM

Quote:

Originally Posted by Skaperen

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?

Skaperen · 06-08-2011, 09:09 AM

Quote:

Originally Posted by dyasny

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.

Slax-Dude · 06-08-2011, 09:12 AM

@Skaperen

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.

I use libvirt, one of the available management tools you are not inspired to use

Code:

#!/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