[libvirt] [Qemu-devel] live snapshot wiki updated

[Eric Blake]

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 at redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org