Yes I've experienced this (or something very similar) myself, for example clicking the Shut Down button in virt-manager's guest window doesn't seem to do anything.
When the "system_powerdown" HMP command is issued, qemu does the following [hmp-commands.hx]:
hmp_system_powerdown()
qmp_system_powerdown()
qemu_system_powerdown_request()
powerdown_requested = 1
...
Then, in the main loop,
main_loop_should_exit()
qemu_powerdown_requested()
qemu_system_powerdown()
notifier_list_notify(&powerdown_notifiers)
The powerdown notifier list is extended with qemu_register_powerdown_notifier(), one such caller is:
piix4_pm_initfn()
qemu_register_powerdown_notifier()
and the callback function is piix4_pm_powerdown_req(). Which does:
piix4_pm_powerdown_req()
acpi_pm1_evt_power_down()
if ACPI_BITMASK_POWER_BUTTON_ENABLE, then
set ACPI_BITMASK_POWER_BUTTON_STATUS flag,
(via funcptr) pm_update_sci()
which should ultimately raise the System Control Interrupt in the guest.

I verified in a RHEL-6 guest (on a RHEL-7 host) that SCI is injected
correctly, IRQ 9 (named "acpi") in /proc/interrupts is bumped by one each
time I click the Shut Down button.
The same bump is visible in the RHEL-7 guest as well, but the RHEL-7 guest
even shuts down consequently. Seeing this, I repeated the test using the
monitor:
# virsh qemu-monitor-command fw-seabios7.g-rhel7.e-rhel7 \
--hmp system_powerdown
and indeed the RHEL-7 guest shut down again.
I think I'll have to explore this systematically, as the reports here and in
bug 907711 seem to be somewhat inconsistent.
Regarding q35 testing: since RHEL-7 libvirt doesn't seem to support q35 yet
(see eg. bug 819968), I must check it using the qemu-kvm command line:
/usr/libexec/qemu-kvm \
-M q35 \
-S \
-enable-kvm \
-m 4096 \
-monitor stdio \
-vga cirrus \
-netdev user,id=net0 \
-device virtio-net-pci,netdev=net0 \
-drive file=/var/lib/libvirt/images/clone.img,if=virtio,format=qcow2 \
-no-kvm-pit-reinjection \
-rtc base=localtime,clock=host,driftfix=slew \
-smp 4 \
-vnc :1
(I started with the command line in comment #0 and trimmed it down until it
was something usable.)
Host components:
- kernel: 3.10.0-0.rc7.64.el7
- qemu-kvm-1.5.0-2.el7
- seabios-bin: 1.7.2.2-2.el7
- libvirt*: 1.0.6-1.el7
- poweroff attempt: via HMP command quoted above
Results:
guest | 3.10.0-0.rc7.64.el7 | 2.6.32-358.el6
--------------+---------------------+-----------------------------
pc-q35-1.5 | works | doesn't work (SCI delivered)
pc-i440fx-1.5 | works | doesn't work (SCI delivered)
In other words, I cannot reproduce the problem with a RHEL-7 guest. I don't
think this has anything to do with my command line being simpler than the
one in comment 0.
I can reproduce the problem with a RHEL-6.4 guest, and for that guest piix4
vs. q35 makes no difference.

I installed "acpid" in the RHEL-6.4 guest, and "system_powerdown" started working immediately.
Sibiao, can you please test the following:
- in the guest, run "watch --interval=0.1 grep acpi /proc/interrupts"
- issue the "system_powerdown" monitor command,
- does that increment any of the counters for IRQ#9 (acpi)?
Also, what does "/etc/systemd/logind.conf" say for "HandlePowerKey" in the guest? See <https://wiki.archlinux.org/index.php/Systemd#ACPI_power_management>.
Thanks.

Thank you for the info. One further question:
> There was a old rhel7 image(kernel-3.7.0-0.36.el7.x86_64) on my host, and
> i tried it with the same steps as comment #0 which did not hit this issue,
> it can do system_powerdown var HMP monitor successfully and the guest can
> be shutdown correctly.
In this test case, did you replace the fresh (RHEL-7.0-20130628.0) image with the old (kernel-3.7.0-0.36.el7) in the host, or in the guest?
If
- your host components (qemu seabios kernel libvirt etc) were unchanged,
- an older RHEL-7 guest image worked correctly,
- and the fresh RHEL-7 guest image doesn't work, *but* the SCI is injected each time,
then this could be a systemd (... or guest kernel configuration?) regression.

Sibiao,
right after you issue the "system_powerdown" command (and nothing happens except the interrupt counter going up), can you please run
journalctl --since=today >journal.txt
and upload that file here?
Because, in the guest,
journalctl --since=today | egrep -i 'power (button|key)'
should produce lines such as:
1 kernel: input: Power Button as
/devices/LNXSYSTM:00/LNXPWRBN:00/input/input0
2 kernel: ACPI: Power Button [PWRF]
3 systemd-logind[455]: Watching system buttons on
/dev/input/event0 (Power Button)
4 systemd-logind[455]: Power key pressed.
Line 1 to line 3 are produced during VM boot and systemd startup.
Line 4 should be produced in response to the "system_powerdown" command. Also, looking at the unfiltered output of
journalctl --since=today
the message
systemd-logind[455]: Power key pressed.
should be directly followed by
systemd-logind[455]: Powering Off...
systemd-logind[455]: System is powering down.
"journal.txt" might allow me more insight to what's happening (and possibly reassign to systemd).
Thanks.

This could be an upstream bug.
Some references:
- https://git.gnome.org/browse/gnome-settings-daemon/commit/?id=6defe42c
- https://bugzilla.gnome.org/show_bug.cgi?id=680689
gsd_media_keys_manager_init() [/plugins/media-keys/gsd-media-keys-manager.c] inhibits "handle-power-key" in systemd via a dbus message. This is in effect as soon as the GDM greetings / user selector screen shows up. In the guest:
# systemd-inhibit --list
[...]
Who: gdm (UID 42/gdm, PID 962/gnome-settings-)
What: handle-power-key:handle-suspend-key:handle-hibernate-key
Why: GNOME handling keypresses
Mode: block
[...]
I can't figure out why the ACPI power button is handled when a user is logged in vs. not handled at all on the greeter screen. GSD_POWER_ACTION_SHUTDOWN sends a Shutdown message to gnome-session (the session manager) over D-Bus, implemented in <https://git.gnome.org/browse/gnome-settings-daemon/commit/?id=f268b2d2>, by calling gnome_session_shutdown().
Well, I do have an idea; and it doesn't look good. Get gnome-session from <https://git.gnome.org/browse/gnome-session>, and change to the "gnome-session" directory in the clone.
The README file explains the startup phases of gnome session manager. The phase names are actually incorrect, the phases must have been renamed slightly with time. In any case, the enum constants are in "gsm-manager.h":
typedef enum {
/* gsm's own startup/initialization phase */
GSM_MANAGER_PHASE_STARTUP = 0,
/* xrandr setup, gnome-settings-daemon, etc */
GSM_MANAGER_PHASE_INITIALIZATION,
/* window/compositing managers */
GSM_MANAGER_PHASE_WINDOW_MANAGER,
/* apps that will create _NET_WM_WINDOW_TYPE_PANEL windows */
GSM_MANAGER_PHASE_PANEL,
/* apps that will create _NET_WM_WINDOW_TYPE_DESKTOP windows */
GSM_MANAGER_PHASE_DESKTOP,
/* everything else */
GSM_MANAGER_PHASE_APPLICATION,
/* done launching */
GSM_MANAGER_PHASE_RUNNING,
/* shutting down */
GSM_MANAGER_PHASE_QUERY_END_SESSION,
GSM_MANAGER_PHASE_END_SESSION,
GSM_MANAGER_PHASE_EXIT
} GsmManagerPhase;
Now let's see how gnome-session handles the Shutdown message:
gboolean
gsm_manager_shutdown (GsmManager *manager,
GError **error)
{
gboolean shell_running;
g_debug ("GsmManager: Shutdown called");
g_return_val_if_fail (GSM_IS_MANAGER (manager), FALSE);
if (manager->priv->phase != GSM_MANAGER_PHASE_RUNNING) {
g_set_error (error,
GSM_MANAGER_ERROR,
GSM_MANAGER_ERROR_NOT_IN_RUNNING,
"Shutdown interface is only available during the Running phase");
return FALSE;
}
When no user is logged in, the gnome session manager is in a phase that differs from RUNNING. If gnome-settings-daemon sends the Shutdown message over D-Bus at this point, in response to the ACPI power button, then gnome-session simply rejects the message.
gnome-session commit 577746e1 is instrumental; originally this used to be called "Logout interface". Clearly logout doesn't make sence if we're not yet logged in, poweroff does though.

>
> When no user is logged in, the gnome session manager is in a phase that
> differs from RUNNING. If gnome-settings-daemon sends the Shutdown message
> over D-Bus at this point, in response to the ACPI power button, then
> gnome-session simply rejects the message.
>
No, that is not true. We run a separate session for the login screen, and the gnome-session running it *is* in the running phase. The process actually handling the power key is gnome-settings-daemon, in the media-keys plugin.

I assume this is a complaint about the default value of the
org.gnome.settings-daemon.plugins.power button-power
key, which is 'suspend'
To test this theory, does the following help ?
cat >/etc/dconf/db/gdm.d/01-power <<EOF
[org/gnome/settings-daemon/plugins/power]
button-power=shutdown
EOF
dconf update
(not 100% sure if the symbolic enum value for button-power works there, please try an explicit
button-power=2
as well

(In reply to Matthias Clasen from comment #15)
> I assume this is a complaint about the default value of the
> org.gnome.settings-daemon.plugins.power button-power
> key, which is 'suspend'
>
> To test this theory, does the following help ?
>
> cat >/etc/dconf/db/gdm.d/01-power <<EOF
> [org/gnome/settings-daemon/plugins/power]
> button-power=shutdown
> EOF
> dconf update
I already tried this in comment 12 (search for the string "org/gnome/settings-daemon/plugins/power"), and it didn't work.
I tried again, and it doesn't work now either.
BTW single quotes are needed around the word "shutdown", otherwise the "dconf update" command fails with:
/etc/dconf/db/gdm.d/01-poweroff: [org/gnome/settings-daemon/plugins/power]:
button-power: skipping invalid value: shutdown (0-8:unknown keyword)
But, again, even if the quoting is correct, the setting has no effect.
> (not 100% sure if the symbolic enum value for button-power works there,
> please try an explicit
>
> button-power=2
>
> as well
Now I've tried this too (+ dconf update + guest reboot). It has no effect, the shutdown button still doesn't work when on the graphical login / user selection screen. After login, shutdown works.

The problem is that gnome-settings-daemon disables the Power key when not in "normal" or "overview" modes:
https://git.gnome.org/browse/gnome-settings-daemon/tree/plugins/media-keys/shortcuts-list.h?h=gnome-3-8#n148
This was meant to avoid people shutting machines down when on the screensaver. Except that that wouldn't stop somebody pressing the button for 5 seconds to switch the machine off anyway.
The fix is simple enough:
- { POWER_KEY, NULL, N_("Power Off"), "XF86PowerOff", GSD_KEYBINDING_MODE_LAUNCHER },
+ { POWER_KEY, NULL, N_("Power Off"), "XF86PowerOff", GSD_KEYBINDING_MODE_ALL },
See the discussion in:
https://bugzilla.gnome.org/show_bug.cgi?id=707095
We'll probably need a few more changes on top of that patch to make sure that we never show dialogues in the lock screen though.

This bug is still present in RHEL-7.1.
I guess that's because blocking bug 1028451 has not been touched by its assignee ever since Bastien filed that bug, SIXTEEN months ago (see comment 20). Nice job!

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://rhn.redhat.com/errata/RHBA-2015-2157.html

Note

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