Re: [Qemu-discuss] Failed to get "consistent read" lock on a mirroring image

[Fam Zheng]

On Tue, 11/21 09:53, Han Han wrote:
> On Mon, Nov 20, 2017 at 4:47 PM, Fam Zheng <address@hidden> wrote:
> 
> > On Mon, 11/20 10:58, Han Han wrote:
> > > Hello,
> > > On qemu-2.10, I find 'qemu-img info' couldn't get the info of a mirroring
> > > image:
> > > # /usr/libexec/qemu-kvm -name A -machine pc,accel=kvm \
> > > -vnc 0.0.0.0:1 \
> > > -monitor stdio \
> > > -qmp tcp:0:5555,server,nowait \
> > > -serial unix:/tmp/monitor,server,nowait \
> > > -drive
> > > file=/var/lib/libvirt/images/V.qcow2,format=qcow2,if=none,
> > id=drive-virtio-blk0,werror=stop,rerror=stop
> > > \
> > > -device virtio-blk-pci,drive=drive-virtio-blk0,id=virtio-blk0
> > >
> > > QEMU 2.10.0 monitor - type 'help' for more information
> > > (qemu) drive_mirror drive-virtio-blk0 /var/lib/libvirt/images/V.new
> > > Formatting '/var/lib/libvirt/images/V.new', fmt=qcow2 size=10737418240
> > > cluster_size=65536 lazy_refcounts=off refcount_bits=16
> > >
> > > # qemu-img info /var/lib/libvirt/images/V.new -U
> > > qemu-img: Could not open '/var/lib/libvirt/images/V.new': *Failed to get
> > > "consistent read" lock*
> > > Is another process using the image?
> >
> > Cc Kevin. Looks like -U here is not strong enough to skip the "consistent
> > read"
> > lock. The drive mirror target BB shared permissions are different from
> > device
> > BB, but I'm not sure if it is intentional.
> >
> > What is the use case behind this test senario? Is it issue hit by libvirt?
> >
> In libvirt we test blockcopy with options and using 'qemu-img info' to
> check if mirroring image's metadata matches the origin's.
> This issue causes several automated cases failed in libvirt.

As a workaround you can use

  $ qemu-img info --image-opts file.locking=off,file.filename=$filename

Fam