Description of problem: Upon clicking the powerbutton icon pulldown menu and choosing the Shut Down option, the VM isn't shut down. virsh list reports the VM state as pmsuspended. Version-Release number of selected component (if applicable): virt-manager-0.10.0-5.git1ffcc0cc.fc20.noarch qemu-common-1.6.1-2.fc20.x86_64 libvirt-daemon-kvm-1.1.3.2-1.fc20.x86_64 kernel-3.13.0-0.rc4.git0.1.fc21.x86_64 How reproducible: Most of the time. Some of the time it appears to shut down, virt-manager window set to "Guest not running". Steps to Reproduce: 1. Install Fedora 20 DVD ISO, only desktop packageset 2. enable updates-testing, yum update 3. yum groupinstall Virtualization Actual results: virt-manager= Black screen virsh list= state is pmsuspend Expected results: virt-manager= grayscreen, Guest not running virsh list= state is shut off Additional info: # rpm -q qemu package qemu is not installed # rpm -q libvirt package libvirt is not installed
Created attachment 837982 [details] virsh console, guest boot and startup [root@f20s images]# ps -ef | grep -i qemu qemu 22021 1 16 14:26 ? 00:00:02 /usr/bin/qemu-system-x86_64 -machine accel=kvm -name fedora20 -S -machine pc-i440fx-1.6,accel=kvm,usb=off -m 1536 -realtime mlock=off -smp 2,sockets=2,cores=1,threads=1 -uuid 479c1e34-3b00-425c-9eb7-21ef5b7e7890 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/fedora20.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=discard -no-hpet -no-shutdown -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x5.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x5 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x5.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x5.0x2 -drive file=/var/lib/libvirt/images/fedoraA.img,if=none,id=drive-virtio-disk0,format=qcow2,cache=unsafe,aio=native -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=drive-virtio-disk0,id=virtio-disk0 -drive file=/mnt/isos/Fedora-Live-Desktop-x86_64-20-1.iso,if=none,id=drive-ide0-0-0,readonly=on,format=raw,cache=unsafe,aio=threads -device ide-cd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 -netdev tap,fd=23,id=hostnet0,vhost=on,vhostfd=24 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:c3:de:c3,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -vnc 127.0.0.1:0 -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,bus=pci.0,addr=0x2 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x8
-no-shutdown seems like the wrong option to pass by default for a virt-manager guest doesn't it? "Don't exit QEMU on guest shutdown, but instead only stop the emulation." That's not at all the behavior described by the word "Shut Down" so if the behavior isn't actually going to be a shutdown then I think the GUI term used needs to be something else. virsh shutdown has the same behavior, it actually goes to pmsuspend. So if this is the intended behavior, then I think Shut Down needs to read "Suspend" instead. Otherwise this is rather unintuitive.
-no-shutdown is used so that libvirt can be notified when a shutdown is requested and do some internal things. it's not the issue here. the issue here is that the 'shutdown' command just issues an ACPI shutdown request of the guest, which is the same as pressing the power button on a physical machine. depending on your desktop environment (or lack thereof), this will do different things. on gnome it'll suspend your machine. I agree it's confusing, and suspend/hibernate isn't much useful in a VM anyways when we have managedsave, but the only way around this is to disable suspend/hibernate capability in the VM XML. This is what gnome-boxes does by default and I think virt-manager should do it too. It won't apply to pre-existing VMs, only newly created ones. The magic XML is: <pm><suspend-to-mem enabled='no'/><suspend-to-disk enabled='no'/></pm> So 'virsh edit' your VM and stick that under <domain>, reboot, and shutdown will do something more akin to what you expect.
How to use virt-manager to resume from this state? I can't figure that out. So the GUI basically puts me in a situation where the VM face plants. Using virsh dompmwakeup doesn't work, it seems the necessary support for pmsuspend isn't in place by default. virsh reports the VM as successfully woken up, yet it isn't. virsh console reports: [ 245.265808] ACPI Error: No installed handler for fixed event - PM_Timer (0), disabling (20130517/evevent-286) [ 245.266719] ACPI Error: No installed handler for fixed event - SleepButton (3), disabling (20130517/evevent-286) [ 245.266719] ACPI Error: Could not disable RealTimeClock events (20130517/evxfevnt-266) [ 245.366751] ACPI Error: No installed handler for fixed event - PM_Timer (0), disabling (20130517/evevent-286) [ 245.367671] ACPI Error: No installed handler for fixed event - SleepButton (3), disabling (20130517/evevent-286) [ 245.367671] ACPI Error: Could not disable RealTimeClock events (20130517/evxfevnt-266) [ 245.418474] ACPI Error: No installed handler for fixed event - PM_Timer (0), disabling (20130517/evevent-286) [ 245.419393] ACPI Error: No installed handler for fixed event - SleepButton (3), disabling (20130517/evevent-286) [ 245.419393] ACPI Error: Could not disable RealTimeClock events (20130517/evxfevnt-266) [ 245.471443] ACPI Error: No installed handler for fixed event - PM_Timer (0), disabling (20130517/evevent-286) [ 245.472363] ACPI Error: No installed handler for fixed event - SleepButton (3), disabling (20130517/evevent-286) [ 245.472363] ACPI Error: Could not disable RealTimeClock events (20130517/evxfevnt-266) Is there more than one bug here?
Yeah I think there's another issue that suspend is broken for VMs on F20 as well, which makes this extra crappy.
(In reply to Cole Robinson from comment #3) > The magic XML is: > <pm><suspend-to-mem enabled='no'/><suspend-to-disk enabled='no'/></pm> State remains at running rather than promptly going to pmsuspend. But after 3 minutes it's still running, with black screen. Hmmm, virsh console judo time.
Looks like it's still trying to suspend but now not succeeding so it hangs at running: 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 1794 systemd-suspend.service changed dead -> start Set up jobs progress timerfd. Set up idle_pipe watch. [ 116.992560] PM: Syncing filesystems ... done. [ 117.387807] Freezing user space processes ... (elapsed 0.039 seconds) done. [ 117.472100] Freezing remaining freezable tasks ... (elapsed 0.006 seconds) done. [ 118.185088] PM: suspend of devices complete after 673.752 msecs [ 118.211971] PM: late suspend of devices complete after 0.178 msecs [ 118.220958] PM: noirq suspend of devices complete after 4.054 msecs qemu 22725 1 25 15:02 ? 00:00:22 /usr/bin/qemu-system-x86_64 -machine accel=kvm -name fedora20 -S -machine pc-i440fx-1.6,accel=kvm,usb=off -m 1536 -realtime mlock=off -smp 2,sockets=2,cores=1,threads=1 -uuid 479c1e34-3b00-425c-9eb7-21ef5b7e7890 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/fedora20.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=discard -no-hpet -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x5.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x5 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x5.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x5.0x2 -drive file=/var/lib/libvirt/images/fedoraA.img,if=none,id=drive-virtio-disk0,format=qcow2,cache=unsafe,aio=native -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=drive-virtio-disk0,id=virtio-disk0 -drive file=/mnt/isos/Fedora-Live-Desktop-x86_64-20-1.iso,if=none,id=drive-ide0-0-0,readonly=on,format=raw,cache=unsafe,aio=threads -device ide-cd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 -netdev tap,fd=23,id=hostnet0,vhost=on,vhostfd=24 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:c3:de:c3,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -vnc 127.0.0.1:0 -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,bus=pci.0,addr=0x2 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x8
Upstream turns this off by default for new VMs now
virt-manager-1.0.0-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/virt-manager-1.0.0-1.fc20
virt-manager-1.0.0-2.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/virt-manager-1.0.0-2.fc20
Package virt-manager-1.0.0-2.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing virt-manager-1.0.0-2.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-2789/virt-manager-1.0.0-2.fc20 then log in and leave karma (feedback).
virt-manager-1.0.0-3.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/virt-manager-1.0.0-3.fc20
virt-manager-1.0.0-3.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.