Version-Release number of selected component (if applicable):

Host:
kernel-3.10.0-306.0.1.el7.x86_64
qemu-kvm-1.5.3-101.el7

Guest:
kernel-3.10.0-309.el7.x86_64


BTW, also hit this issue with qmp command {"execute": "system_powerdown"}

in guest
#runlevel
N 5

 
# init 3
then (qemu) system_powerdown, not hit this issue.

Reproducible on:
kernel-3.10.0-418.el7.x86_64
qemu-kvm-1.5.3-112.el7.x86_64

As comment 3 shows, this is the guest trying to do a hibernate / suspend instead of a shutdown.

Using qemu commands for effecting shutdown isn't guaranteed to produce desired results, because the guest can (and, indeed, does) influence the action on such commands.

The safest way to shutdown a guest from the host is to issue commands via libvirt, which routes through the guest agent.

Perhaps QE can update the test cases to not use the qemu commands, since what the guest does on receiving those commands is not in our control, unless those commands are routed through the guest-agent.

system_powerdown triggers a System Control Interrupt in the guest.  The guest can react to it however it likes.  As long as qemu-kvm triggers an SCI, there is no qemu-kvm bug.

Closely related: bug 980692.  It was filed against qemu-kvm with the title "fail to poweroff guest when do system_powerdown in HMP monitor if did not login guest", and reassigned to gdm with the title changed to "gdm login screen in VMs: the ACPI power button should by default effect a shutdown".  The actual bug we fixed there was the guest's reaction to SCI while gdm is running.

To double-check it's the guest's decision not to shutdown, please

* confirm that shutdown works in run level 3, and

* retest run level 5 with a guest that has bug 980692 fixed.

Additionally:

* The expected result of tests involving system_powerdown depends on the guest.  Therefore, the test plan needs to spell out how to get the guest into a defined state that reliably produces the expected result.  Please confirm the test plan does that.

* Please confirm the test plan covers the preferred way to shut down guests, namely via libvirt commands to make the guest agent shut it down.

(In reply to Markus Armbruster from comment #7)
> system_powerdown triggers a System Control Interrupt in the guest.  The
> guest can react to it however it likes.  As long as qemu-kvm triggers an
> SCI, there is no qemu-kvm bug.
> 
> Closely related: bug 980692.  It was filed against qemu-kvm with the title
> "fail to poweroff guest when do system_powerdown in HMP monitor if did not
> login guest", and reassigned to gdm with the title changed to "gdm login
> screen in VMs: the ACPI power button should by default effect a shutdown". 
> The actual bug we fixed there was the guest's reaction to SCI while gdm is
> running.
> 
> To double-check it's the guest's decision not to shutdown, please
> 
> * confirm that shutdown works in run level 3, and
> 
> * retest run level 5 with a guest that has bug 980692 fixed.
> 
> Additionally:
> 
> * The expected result of tests involving system_powerdown depends on the
> guest.  Therefore, the test plan needs to spell out how to get the guest
> into a defined state that reliably produces the expected result.  Please
> confirm the test plan does that.
> 
> * Please confirm the test plan covers the preferred way to shut down guests,
> namely via libvirt commands to make the guest agent shut it down.


Confirmed, shutdown works in run level 3, and retested bug 980692, it has fixed.
Will confirm with feature owner and update test plan. Thank you.

Your testing confirms that QEMU works as it should.  Closing NOTABUG.