libvirt users - Jan 2015 - Re: Block Commit: [100 %]error: failed to pivot job for disk vda

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.