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

[Kevin Wolf]

[ Cc: qemu-block ]

Am 20.11.2017 um 09:47 hat Fam Zheng geschrieben:
> 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.

I think there are two parts to this:

First, blocking consistent reads for the mirror target seems
unnecessary. I can send a patch to allow this in 2.11.

The other part is that 'qemu-img info' doesn't actually need
BLK_PERM_CONSISTENT_READ, but blk_new_open() automatically requests it.
Maybe we need another flag that allows 'qemu-img info' to do without
this permission. The concrete use case are intermediate nodes of a
commit job, where we do have to block this permission.

Hm... Or is BDRV_O_NO_IO already the right flag for this? :-)

Kevin