8:19 a.m.
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.
10:46 a.m.
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
11:26 a.m.
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.
8:38 a.m.
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.
2:23 a.m.
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.
3600
days inactive
3607
days old
4 comments
2 participants
participants (2)
-
Eric Blake -
Thomas Stein