[libvirt-users] Block Commit: [100 %]error: failed to pivot job for disk vda
Hello. I'm seeing this error while doing a backup of a VM. + virsh blockcommit kaltura vda --active --verbose --pivot Block Commit: [100 %]error: failed to pivot job for disk vda error: internal error: unable to execute QEMU command 'block-job-complete': The active block job for device 'drive-virtio-disk0' cannot be completed I'm on qemu 2.2.0 and libvirt-1.2.11. Does someone else see this error? Libvirt.log says: 2015-01-07 11:18:07.000+0000: 19355: warning : qemuDomainObjBeginJobInternal:1381 : Cannot start job (query, none) for domain kaltura; current job is (modify, none) owned by (19357, 0) 2015-01-07 11:18:07.000+0000: 19355: error : qemuDomainObjBeginJobInternal:1386 : Timed out during operation: cannot acquire state change lock 2015-01-07 11:18:35.556+0000: 19357: error : qemuMonitorJSONCheckError:381 : internal error: unable to execute QEMU command 'block-job-complete': The active block job for device 'drive-virtio-disk0' cannot be completed Any ideas? thanks and cheers t.
On 01/07/2015 07:19 AM, Thomas Stein wrote:
Hello.
I'm seeing this error while doing a backup of a VM.
+ virsh blockcommit kaltura vda --active --verbose --pivot Block Commit: [100 %]error: failed to pivot job for disk vda error: internal error: unable to execute QEMU command 'block-job-complete': The active block job for device 'drive-virtio-disk0' cannot be completed
Based on this message, it is qemu that is refusing to do the pivot, but I don't know if that is because of permissions on the destination file, or something else (that is, it may still be a libvirt bug for not putting things in the right state for the qemu command to have a chance of succeeding). What distro are you using? Is AppArmor or SELinux at play, where temporarily getting that out of the way might change things?
I'm on qemu 2.2.0 and libvirt-1.2.11.
Does someone else see this error? Libvirt.log says:
2015-01-07 11:18:07.000+0000: 19355: warning : qemuDomainObjBeginJobInternal:1381 : Cannot start job (query, none) for domain kaltura; current job is (modify, none) owned by (19357, 0) 2015-01-07 11:18:07.000+0000: 19355: error : qemuDomainObjBeginJobInternal:1386 : Timed out during operation: cannot acquire state change lock
This may also be the sign of a libvirt bug in not tracking lock states correctly. I've had other reports of bogus behavior, so I'm trying to take another audit of the code this week to see if I can find a problem in the libvirt code. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
On Wednesday 07 January 2015 09:46:09 Eric Blake wrote:
On 01/07/2015 07:19 AM, Thomas Stein wrote:
Hello.
I'm seeing this error while doing a backup of a VM.
+ virsh blockcommit kaltura vda --active --verbose --pivot Block Commit: [100 %]error: failed to pivot job for disk vda error: internal error: unable to execute QEMU command 'block-job-complete': The active block job for device 'drive-virtio-disk0' cannot be completed
Based on this message, it is qemu that is refusing to do the pivot, but I don't know if that is because of permissions on the destination file, or something else (that is, it may still be a libvirt bug for not putting things in the right state for the qemu command to have a chance of succeeding). What distro are you using? Is AppArmor or SELinux at play, where temporarily getting that out of the way might change things?
I'm using Gentoo. There is no selinux or apparmor enabled on this machine. Should i file a bug report? thanks and cheers t.
I'm on qemu 2.2.0 and libvirt-1.2.11.
Does someone else see this error? Libvirt.log says:
2015-01-07 11:18:07.000+0000: 19355: warning : qemuDomainObjBeginJobInternal:1381 : Cannot start job (query, none) for domain kaltura; current job is (modify, none) owned by (19357, 0) 2015-01-07 11:18:07.000+0000: 19355: error : qemuDomainObjBeginJobInternal:1386 : Timed out during operation: cannot acquire state change lock
This may also be the sign of a libvirt bug in not tracking lock states correctly. I've had other reports of bogus behavior, so I'm trying to take another audit of the code this week to see if I can find a problem in the libvirt code.
Am 07.01.15 um 18:26 schrieb Thomas Stein:
Based on this message, it is qemu that is refusing to do the pivot, but I don't know if that is because of permissions on the destination file, or something else (that is, it may still be a libvirt bug for not putting things in the right state for the qemu command to have a chance of succeeding). What distro are you using? Is AppArmor or SELinux at play, where temporarily getting that out of the way might change things?
I'm using Gentoo. There is no selinux or apparmor enabled on this machine. Should i file a bug report?
I colleague of mine pointed me in the right direction. There was a cdrom defined in the virtual machine. After removing it the process runs as expected: + virsh blockcommit kaltura vda --active --verbose --pivot Block Commit: [100 %] Successfully pivoted This leads to the question how would i use blockcommit under those circumstances? Should i detach the cdrom prior blockcommit run? Should i file a bug report? Are you already taking care of this problem Eric? thanks and best regards t.
Am 09.01.15 um 15:38 schrieb Thomas Stein:
Am 07.01.15 um 18:26 schrieb Thomas Stein:
Based on this message, it is qemu that is refusing to do the pivot, but I don't know if that is because of permissions on the destination file, or something else (that is, it may still be a libvirt bug for not putting things in the right state for the qemu command to have a chance of succeeding). What distro are you using? Is AppArmor or SELinux at play, where temporarily getting that out of the way might change things?
I'm using Gentoo. There is no selinux or apparmor enabled on this machine. Should i file a bug report?
A colleague of mine pointed me in the right direction. There was a cdrom defined in the virtual machine. After removing it the process runs as expected:
+ virsh blockcommit kaltura vda --active --verbose --pivot Block Commit: [100 %] Successfully pivoted
It seems the real cause is qemu 2.2.0. The error reaccurred the other day even with only one disk configured. After downgrading to qemu-2.1.2 no problems so far. cheers t.
participants (2)
-
Eric Blake -
Thomas Stein