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

[Fam Zheng]

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?

> 
> 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