how to (properly) shut down a fedora 20 virtual machine?
lists at colorremedies.com
Tue Dec 17 20:46:35 UTC 2013
On Dec 17, 2013, at 12:59 PM, Chris Murphy <lists at colorremedies.com> 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 suspend.target/start/replace-irreversibly
Installed new job suspend.target/start as 1106
Installed new job systemd-suspend.service/start as 1107
Installed new job sleep.target/start as 1108
Enqueued job suspend.target/start as 1106
sleep.target changed dead -> active
Job sleep.target/start 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.
More information about the users