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.
> > > > > 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: h...@redhat.com Phone: +861065339333
