how to (properly) shut down a fedora 20 virtual machine?

Chris Murphy lists at
Tue Dec 17 20:46:35 UTC 2013

On Dec 17, 2013, at 12:59 PM, Chris Murphy <lists at> wrote:
> Urgh. I think this is a bug getting the external shutdown message passed into the VM. So this might mean setting up the VM with a serial device, and using virsh console so that even if it gets networking in the VM all shutdown, you can still control and see what's happening, or in this case what's not happening..

OK, I have a completely new F20 baremetal host installed (from DVD ISO, default desktop packageset without libreoffice and no other additions), with updates-testing enabled, all updates applied, and with group Virtualization installed. One non-stock thing I'm doing is running kernel 3.13.0-0.rc4.git0.1.fc21. This is not a debug kernel.

Booting Fedora 20 Live Desktop with virt-manager, get to the desktop and immediate go to virt-manager's powerbutton icon pulldown menu and choose Shut Down. It takes a while but it down eventually shutdown the VM. If I retry this with virsh shutdown, it also works, eventually.

However, I just tried yet again, using virsh console to see if it's the same bug as before, and I get the result you've got, black screen. But virsh list reports the VM as "pmsuspended" even though I clearly chose Shut Down. Serial console reports this:

Trying to enqueue job
Installed new job as 1106
Installed new job systemd-suspend.service/start as 1107
Installed new job as 1108
Enqueued job as 1106 changed dead -> active
Job finished, result=done
About to execute: /usr/lib/systemd/systemd-sleep suspend
Forked /usr/lib/systemd/systemd-sleep as 1813
systemd-suspend.service changed dead -> start
Set up jobs progress timerfd.
Set up idle_pipe watch.
[   98.381270] PM: Syncing filesystems ... done.
[   98.772061] Freezing user space processes ... (elapsed 0.001 seconds) done.
[   98.833275] Freezing remaining freezable tasks ... (elapsed 0.007 seconds) done.
[   98.861637] Suspending console(s) (use no_console_suspend to debug)

So that's consistent with what you're seeing I think. I got sick of the user at 0.service bug causing delays and formed the habit of using virsh destroy. Looks like a totally separate bug here.

Chris Murphy

More information about the users mailing list