On Tue, 11/21 09:53, Han Han wrote: > On Mon, Nov 20, 2017 at 4:47 PM, Fam Zheng <f...@redhat.com> 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
