On 07/21/2011 03:34 AM, Jes Sorensen wrote:
On 07/21/11 11:34, Daniel P. Berrange wrote:
QEMU is *not* yet running at the time libvirt reads the file metadata.
Of course it is: hotplug
In the case of hotplug, the hotplug monitor commands have not yet been
invoked when libvirt access the file metadata, or the drive has already
been unplugged, so there is still no concurrent access to the file by
QEMU and libvirt.
Unless someone tries to hotplug an image that relies on a backing file
already used by another image. While unlikely, it is possible.
Backing images should be treated as read-only by qemu, right? That is,
if I have file c.img which uses ca.img as its backing file, then qemu
only needs O_RDONLY access to ca.img, right? My understanding is that
you never want to have a qcow2 image whose backing file is being
simultaneously edited by another external process, otherwise you risk
data corruption from the point of view of the qemu process that is
trying to refer to that backing file.
Given that restriction, if I want to hotplug file d.img that _also_ uses
ca.img as its backing file, then that's not an issue. Libvirt _still_
reads the metadata of d.img, and learns of the backing file of ca.img,
all before calling the hotplug command, even if ca.img is already in use
by qemu, with no complications.
You still haven't managed to convince me that there is ever any
situation where qemu needs to open a backing file that is not already
determined /a priori/ by reading just the metadata of the files being
handed to qemu in the first place, or by being aware of the metadata
relationship being requested of qemu in the first place (such as the
relationship implied by calling snapshot_blkdev to create a qcow2 file
with an existing file as backing).
--
Eric Blake eblake@xxxxxxxxxx +1-801-349-2682
Libvirt virtualization library http://libvirt.org
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list