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

[Han Han]

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.

>
> >
> > But in qemu-2.9, it works. So is it expected result? Or a new feature in
> > qemu-2.10?
>
> But yes, the whole image locking feature is new in 2.10.
>
> Fam
>



-- 
Han Han
Quality Engineer
Redhat.

Email: address@hidden
Phone: +861065339333