[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Fam Zheng
Subject: Re: [Qemu-discuss] Failed to get "consistent read" lock on a mirroring image
Date: Mon, 20 Nov 2017 16:47:50 +0800
User-agent: Mutt/1.9.1 (2017-09-22)

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]