Description of problem: I can not shutdown a VM guest. No matter how I try to stop the guest, it appears to begin the shutdown then the virtual machine CPU utilization goes to 100% indefinitely. Version-Release number of selected component (if applicable): libvirt.x86_64 1.0.5.6-3.fc19 @updates libvirt-client.x86_64 1.0.5.6-3.fc19 @updates libvirt-daemon.x86_64 1.0.5.6-3.fc19 @updates libvirt-client.x86_64 1.1.3.1-1.fc20 @updates-testing libvirt-daemon.x86_64 1.1.3.1-1.fc20 @updates-testing How reproducible: Consistent Steps to Reproduce: 1. Build a new VM guest using virt-manager 2. Shutdown the new guest Actual results: The shutdown appears to begin, then the VM guest CPU utilization goes to 100% indefinitely. Expected results: Shutdown Additional info: 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.
Dean, I noticed you commented on BZ 1015732 that you were seeing that hang on shutdown/reboot. This looks like a duplicate of that BZ to me, as I see CPU go to 100% in that case. I'm thinking we should reopen that one (I'm still seeing it on fully updated F19 host/fully updated F19 guest) although not rawhide guests AFAIK). Was there something else you wanted to cover with this BZ?
OK, please re-open BZ 1015732. Because it remained closed, after I added my first comment, it did not show on my open bug list and in my frustration I forgot about it. Sorry. *** This bug has been marked as a duplicate of bug 1015732 ***