I have what appears to be a bug when pivoting a disk during a block copy that is not yet 100% finished, resulting in the pivot command hanging. I have verified this problem on libvirt 1.2.10.
Here's what Im seeing (transient guest): 1.) Start the block copy: [root@host ~]# virsh blockcopy f20-SPICE vda /dev/sdc --format=raw --blockdev Block Copy started [root@host ~]# 2.) Query status to see it works/is started [root@host ~]# virsh blockjob --info f20-SPICE vda Block Copy: [ 1 %] [root@host ~]# 3.) Attempt the pivot before mirror reaches 100% (this makes cmd hang) [root@test-parent-kvm ~]# virsh blockjob f20-SPICE vda --pivot ^^^ cmd is now hanging ------------------------------------------------------------- When its hanging, I see this in /var/log/libvirt/libvirtd.log 19:29:33.376+0000: 1845: error : qemuDomainBlockPivot:15367 : block copy still active: disk 'vda' not ready for pivot yet 19:30:31.000+0000: 1842: warning : qemuDomainObjBeginJobInternal:1376 : Cannot start job (query, none) for domain f20-SPICE; current job is (modify, none) owned by (1845, 0) 19:30:31.000+0000: 1842: error : qemuDomainObjBeginJobInternal:1381 : Timed out during operation: cannot acquire state change lock This then makes other commands querying this domain hang as well, such as: virsh blockjob --info f20-SPICE vda With this being put into log: 19:30:31.000+0000: 1842: error : qemuDomainObjBeginJobInternal:1381 : Timed out during operation: cannot acquire state change lock 19:34:45.568+0000: 1841: error : virNetSocketReadWire:1571 : End of file while reading data: Input/output error Is this expected behavior? It would be nice if on step #3 instead of hanging the command returned in an error state saying cannot pivot because the mirror is not yet 100% or similar. I am happy to test later versions or patches as needed. -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
