Fully updated F20 running in KVM almost always hangs on shutdown/reboot and must be forced off. I wish I could be more specific, but there isn't any output on the screen; gnome-shell terminates and then I get a blinking underline cursor at the top left corner of the screen. If this wasn't nearly 100% reproducible for me, I wouldn't even bother filing a bug report, but something is clearly broken here. Any guidance on what information I could gather to understand where it's hanging would be much appreciated.
Dave, add a serial console to the guest, direct all kernel messages to it (ie: console=tty0 console=ttyS0,115200), and see if it spits out any messages while hanging. For additional points, add a getty on the console, log in, and tail some logs. http://rwmj.wordpress.com/2011/07/08/setting-up-a-serial-console-in-qemu-and-libvirt/#content An alternative method: - Ensure that rsyslog is installed, since in F20 it's not necessarily the case that log files are being generated. - Use virt-ls + virt-cat to see what files are being updated during the hang, and to list out log files. $ virt-ls -d guest -lR --time-relative / | grep '^-' > /tmp/files # see which files changed in the last 120 seconds: $ awk '$6 < 120' < /tmp/files # cat files of interest: $ virt-cat -d guest /var/log/messages | less http://rwmj.wordpress.com/2012/02/27/using-libguestfs-to-find-out-why-a-windows-guest-was-hanging/#content
I was reproducing this around time of the test day, but it's working fine with latest F20 in a VM now, so closing. If someone can still reproduce, please reopen.
I have this problem with a Fedora 19 host and Fedora 19 or Fedora 20 beta guests.
I am using a Fedora 19 VM host with either a Fedora 19 VM guest or Fedora 20-beta guest. I have tried the default guest configuration created by virt-manager, configuring the acpi guest, and configuring the qemu-guest-agent. They all have the same results. What am I doing wrong? virt-install \ --autostart \ --connect qemu:///system \ --disk vol=Guests/test.example.com,bus=virtio \ --extra-args inst.ks=file:/Kickstart.3037 \ --graphics spice \ --initrd-inject /tmp/Kickstart.3037 \ --location http://192.168.2.10/isos/fedora20 \ --name test.example.com \ --network network=Subnet2 \ --os-type linux \ --ram 2048 \ --soundhw es1370 --vcpus 2 The kickstart file includes: @guest-desktop-agents in the packages section.
*** Bug 1030103 has been marked as a duplicate of this bug. ***
(In reply to Cole Robinson from comment #2) > I was reproducing this around time of the test day, but it's working fine > with latest F20 in a VM now, so closing. If someone can still reproduce, > please reopen. I'm still seeing this BZ on fully updated F19 host/fully updated F19 guest, so I'm reopening. My sense is that this behavior is guest OS related, as I *think* it's not happening on my rawhide guest. I'll gather some more data about what guests seem to experience it and update the BZ.
Hmm, this is reproducing for me even with a fully updated F20 guest.
After updating to kernel 3.11.8-300.fc20.x86_64, I see new behavior on a guest configured with the qemu guest agent and corresponding channel: Reboot 1) "sudo reboot" rom a terminal command prompt works 2) From the system controls (upper right-hand corner) works 3) From the Virtual Machine buttons works 4) "virsh reboot test.example.com --mode agent" stalls on the Plymouth(?) screen for 90 seconds minutes with low CPU utilization before completing Shutdown 1) "sudo shutdown now" from a terminal command prompt works 2) From the system controls (upper right-hand corner) works 3) From the Virtual Machine menu or buttons works 4) "virsh shutdown test.example.com -mode agent" stalls for 90 seconds minutes with low CPU utilization before completing
On a new VM built with kernel 3.11.8-300.fc20.x86_64 and no qemu guest agent channel: Reboot 1) "sudo reboot" from a terminal command prompt stalls on the Plymouth(?) screen for 90 seconds minutes with low CPU utilization before completing 2) From the system controls (upper right-hand corner) stalls for 90 seconds minutes with low CPU utilization before completing 3) From the Virtual Machine buttons ignored 4) "virsh reboot test.example.com" ignored Shutdown 1) "sudo shutdown now" from a terminal command prompt works 2) From the system controls (upper right-hand corner) stalls for 90 seconds minutes with low CPU utilization before completing 3) From the Virtual Machine menu or buttons ignored 4) "virsh shutdown test.example.com" ignored
This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '20'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 20 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.