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 ***