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.

All four results identical with qemu-kvm-1.5.1-2.el7.x86_64.

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.

bug 927609 could be related

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.

Not sure if this is a duplicate of bug 927609, but very closely related.

I installed @gnome-desktop in my RHEL-7 guest, pointed to
"/etc/systemd/system/default.target" symlink at
"/lib/systemd/system/graphical.target", and rebooted.

Indeed the Shut Down button of the virt-manager window has stopped working,
and so has the

  virsh qemu-monitor-command fw-seabios7.g-rhel7.e-rhel7 \
      --hmp system_powerdown

host-side command.

These are the relevant startup messages from the journal (journalctl
--since=today):

  systemd-logind[461]: New session c1 of user gdm.

  systemd[1]: Starting Daemon for power management...
  dbus-daemon[467]: dbus[467]: [system] Successfully activated service
                               'org.freedesktop.UPower'
  dbus[467]: [system] Successfully activated service
             'org.freedesktop.UPower'
  systemd[1]: Started Daemon for power management.

Then, this is all that happens in response to the Shut Down button in
virt-manager:

  systemd-logind[461]: Power key pressed.

No subsequent

  systemd-logind[455]: Powering Off...
  systemd-logind[455]: System is powering down.

messages; clearly HandlePowerKey has been inhibited.

  # loginctl

   SESSION        UID USER             SEAT
        c1         42 gdm              seat0
         3          0 root

(Note that session 3 was not active when I tried to power off the VM, I
logged in over SSH only to run loginctl.)

  # loginctl session-status c1

  c1 - gdm (42)
             Since: Wed 2013-07-10 12:02:48 CEST; 10min ago
            Leader: 587 (gdm-session-wor)
              Seat: seat0; vc1
           Display: :0
           Service: gdm-launch-environment; type x11; class greeter
             State: active
            CGroup: systemd:/user/42.user/c1.session
                    |- 587 gdm-session-worker [pam/gdm-launch-environment]
                    |- 790 /usr/bin/gnome-session \
                    |      --autostart /usr/share/gdm/greeter/autostart
                    |- 805 /usr/bin/dbus-launch \
                    |      --exit-with-session /usr/bin/gnome-session \
                    |      --autostart /usr/share/gdm/greeter/autostart
                    |- 940 /bin/dbus-daemon --fork --print-pid 4 \
                    |      --print-address 6 --session
                    |- 944 /usr/libexec/at-spi-bus-launcher
                    |- 948 /bin/dbus-daemon \
                           --config-file=/etc/at-spi2/accessibility.conf \
                           --nofork --print-address 3
                    |- 952 /usr/libexec/at-spi2-registryd \
                           --use-gnome-session
                    |- 962 /usr/libexec/gnome-settings-daemon
                    |-1018 gnome-shell --mode=gdm
                    |-1026 /usr/bin/pulseaudio --start --log-target=syslog
                    `-1049 /usr/libexec/dconf-service

The "upower" daemon <http://upower.freedesktop.org/docs/>, version
upower-0.9.20-1.el7, is running:

  # systemctl status upower

  upower.service - Daemon for power management
     Loaded: loaded (/usr/lib/systemd/system/upower.service; disabled)
     Active: active (running) since Wed 2013-07-10 12:02:51 CEST; 14min ago
       Docs: man:upowerd(8)
   Main PID: 971 (upowerd)
     CGroup: name=systemd:/system/upower.service
             `-971 /usr/libexec/upowerd

  Jul 10 12:02:51 localhost.localdomain systemd[1]: Started Daemon for power
                                                    management.

However the Loaded line says it is "disabled". Indeed, running "upower
--monitor-detail" and clicking the Shut Down button again, prints nothing.


This is a GNOME configuration bug.
----------------------------------

If I actually log in to the GUI in the guest, then the Shut Down button
starts working, but it only suspends the virtual machine, instead of
shutting it down. This originates form the following gnome configuration
item:

  # gsettings get org.gnome.settings-daemon.plugins.power button-power
  'suspend'

  # gsettings list-recursively org.gnome.settings-daemon.plugins.power
  ...
  org.gnome.settings-daemon.plugins.power button-hibernate 'hibernate'
  org.gnome.settings-daemon.plugins.power button-power 'suspend'
  org.gnome.settings-daemon.plugins.power button-sleep 'hibernate'
  org.gnome.settings-daemon.plugins.power button-suspend 'suspend'
  ..  

See
<https://wiki.archlinux.org/index.php/GNOME#Make_the_power_button_interactive>.

Problems:
- I cannot change the value from a root shell:
  
  # gsettings set org.gnome.settings-daemon.plugins.power button-power shutdown

  (process:1381): dconf-WARNING **: failed to commit changes to dconf: Error
  spawning command line `dbus-launch
  --autolaunch=4734061f583b1094ba6d2e38e9a124dd --binary-syntax
  --close-stderr': Child process exited with code 1

- When no user is logged in via gdm, then not even suspend works. It simply
  does nothing.
  
- I tried to change the system-wide default, following the instructions in
  <https://wiki.gnome.org/dconf/SystemAdministrators>:
  
  (a) created the file "/etc/dconf/db/gdm.d/01-poweroff" with the following
  contents:
  
  [org/gnome/settings-daemon/plugins/power]
  button-power='shutdown'

  (b) ran "dconf update"
  
  (c) rebooted the guest
  
  (d) no change in behavior


... I installed "dconf-editor" and ran it in the GUI session. I navigated
to  org/gnome/settings-daemon/plugins/power, and set "button-power" to
"shutdown". Then clicking virt-manager's Shut Down button pulls up a dialog,
asking/warning the user about powering off in 60 seconds.

If in addition I set "logout-prompt" to "false", under
org/gnome/SessionManager, then virt-manager's Shut Down button finally does
what it should, but again, only when a user is logged in via GDM. On the GDM
login screen, nothing happens.

I'm moving this BZ over to gdm.

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

If the request is for the power button to shutdown, it should be as easy as modifying gdm's GSettings in /etc/dconf/db/gdm.d/00-upstream-settings.

Was that it?

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

2 patches to cherry-pick from upstream:
https://git.gnome.org/browse/gnome-settings-daemon/commit/plugins/media-keys?id=14bc784ec6fe2a6d207be4074b6c8982562f099a
and
https://git.gnome.org/browse/gnome-settings-daemon/commit/plugins/media-keys?id=af2f36d23bc72da0bda490aa2c2e89fad793742b

And the patch attached to:
https://bugzilla.gnome.org/show_bug.cgi?id=707095

Turns out that's not quite enough, and there are a couple of bugs in gnome-shell that need fixing before that's possible.

I filed https://bugzilla.redhat.com/show_bug.cgi?id=1028451 about this.

*** Bug 1040307 has been marked as a duplicate of this bug. ***

*** Bug 1163712 has been marked as a duplicate of this bug. ***

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!

This got fixed upstream, and will be in the rebased GNOME in RHEL 7.2.

*** Bug 1231600 has been marked as a duplicate of this bug. ***

*** Bug 1242075 has been marked as a duplicate of this bug. ***

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