Red Hat Bugzilla – Bug 705435
Unable to destroy VM when NFS share holding iso mounted as virtual disk disappears
Last modified: 2012-06-06 20:45:55 EDT
I have a qemu/KVM virtual machine with a .iso file (on a remote NFS share) mounted as a virtual CDROM drive. After the VM was booted, the machine hosting the NFS share was turned off. When I tried to shut down the VM, I got errors from both virsh and VMM. If I turn the NFS share back on, I am able to turn off the VM.
error from virsh:
[root@testlap ~]# virsh destroy f14upgrade
error: Failed to destroy domain f14upgrade
error: Timed out during operation: cannot acquire state change lock
error from VMM:
Dialog box with:
Error shutting down domain: Timed out during operation: cannot acquire state change lock
dialog box details:
Traceback (most recent call last):
File "/usr/share/virt-manager/virtManager/engine.py", line 911, in _do_destroy_domain
File "/usr/share/virt-manager/virtManager/domain.py", line 1168, in destroy
File "/usr/lib64/python2.7/site-packages/libvirt.py", line 346, in destroy
if ret == -1: raise libvirtError ('virDomainDestroy() failed', dom=self)
libvirtError: Timed out during operation: cannot acquire state change lock
libvirtd: 10:42:01.000: 1321: error : qemuDomainObjBeginJobWithDriver:453 : Timed out during operation: cannot acquire state change lock
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. start VM with .iso over NFS as virtual CDROM
2. turn off NFS share without unmounting anything
3. attempt to shutdown VM
Unable to shutdown the virtual machine through virsh or VMM 'force off'.
Shutdown the virtual machine
HW info for VM host:
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
This sounds very similar to bug 746666. At least your case gave a sensible error message instead of deadlocking. I'm not sure if libvirt can ever fully recover from a missing NFS server, but I am trying to work on making a hung NFS have less impact on the rest of libvirt.
Given the limited scope of this problem, and the potential invasiveness of the changes, particularly some of those pointed to in 746666, this will probably never be a fedora backport candidate.
Tim, if you are still seeing issues on F17, please file bugs against libvirt's upstream tracker (Product: Virtualization Tools in this bugzilla).