Bug 835497 - qemu-kvm: VM status is 'running' after guest OS halted
qemu-kvm: VM status is 'running' after guest OS halted
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: qemu-kvm (Show other bugs)
7.0
x86_64 Linux
medium Severity medium
: rc
: ---
Assigned To: Luiz Capitulino
Virtualization Bugs
:
Depends On: 835493
Blocks:
  Show dependency treegraph
 
Reported: 2012-06-26 07:07 EDT by Sibiao Luo
Modified: 2013-04-04 09:34 EDT (History)
12 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-04-04 09:34:28 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Sibiao Luo 2012-06-26 07:07:19 EDT
Description of problem:
start guest with virtio serial and start guest agent inside guest, connect the chardev socket in host side for sending commands to guest, then check the VM status via QEMU and QMP monitor after the guest halt. the sceen of the guest display it halted successfully, but check the VM status via QEMU and QMP monitor was still running, it should be paused. any way, running status is not accurate. 
BTW, the rhel7.0 host also hit this issue, BZ #835493.

Version-Release number of selected component (if applicable):
host info:
# uname -r && rpm -q qemu-kvm
2.6.32-278.el6.x86_64
qemu-kvm-0.12.1.2-2.295.el6.x86_64
guest info: 
kernel-2.6.32-276.el6.x86_64
qemu-guest-agent-0.12.1.2-2.295.el6.x86_64.rpm

How reproducible:
100%

Steps to Reproduce:
1.start guest with virtio serial and start guest agent inside guest.
install the qemu-guest-agent-0.12.1.2-2.295.el6.x86_64.rpm
in guest: # qemu-ga -m virtio-serial -p /dev/virtio-ports/org.qemu.guest_agent.0
2.connect the chardev socket in host side for sending commands to guest.
# nc -U /tmp/qga.sock readline
3.send command in the host side to halt guest.
{ "execute": "guest-shutdown", "arguments":{"mode":"halt"}}
{"return": {}}
4.check the VM status via QEMU and QMP monitor after the guest halt.

Actual results:
after the step 4, the screen of the guest displays as following,
...
Halting system... 
System haltes.

the QEMU monitor,
(qemu) info status 
VM status: running

The QMP monitor,
{ "execute": "query-status"}
{"return": {"status": "running", "singlestep": false, "running": true}}

Expected results:
The VM status should be paused after the guest halt, any way, running status is not correct.

Additional info:
# /usr/libexec/qemu-kvm -enable-kvm -smp 4 -m 4G -usb -device usb-tablet,id=input0 -name RHEL-Server-6.3-64 -uuid `uuidgen` -drive file=/home/rhel6.3.5.31.0.qcow2,if=none,id=drive-virtio-disk-0,format=qcow2,cache=none,werror=stop,rerror=stop -device virtio-blk-pci,drive=drive-virtio-disk-0,id=virtio0,bootindex=1 -netdev tap,script=/etc/qemu-ifup,id=netdev0 -device virtio-net-pci,netdev=netdev0,id=device-net0 -vnc :1 -boot menu=on -monitor stdio -chardev socket,path=/tmp/qga.sock,server,nowait,id=qga0 -device virtio-serial -device virtserialport,chardev=qga0,name=org.qemu.guest_agent.0 -qmp tcp:0:4444,server,nowait
Comment 1 Luiz Capitulino 2012-07-17 13:56:05 EDT
This is not related to qemu-ga, if you try any of the following commands in the guest:

 # system +0 -H (this is what qemu-ga does)

or

 # halt

You'll get the same issue.

What happens is that we don't have a RunState for system halt. This also happens upstream. We can add a 'halted' state or extend the meaning of 'shutdown'.

Thanks for reporting, it's interesting that no one has caught this before.
Comment 5 Paolo Bonzini 2013-04-04 09:34:28 EDT
I think this is not a bug.  It is exactly what happens on a "real" system.  If you want to shutdown the system, do not halt it---use "poweroff".

It is similar to the "guest panicked" event that Fujitsu is adding upstream, but it doesn't matter as much because it only comes after the user's explicit action.  It is not worth adding a PV interface for this.

Note You need to log in before you can comment on or make changes to this bug.