


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

Libvirt virtualization library http://libvirt.org
