Re: [Qemu-devel] live snapshot wiki updated

[Eric Blake <eblake@redhat.com>]

On 07/20/2011 02:01 PM, Blue Swirl wrote:
>> Either because CA was mentioned as a backing file for C (in which case
>> libvirt already knows about it, because either libvirt handed C to qemu at
>> startup time after already parsing C's headers to learn that CA is a backing
>> file, or because libvirt called the snapshot_blkdev command with the intent
>> of having qemu populate CA with C as its backing file), or because qemu has
>> a bug (in which case, libvirt should refuse the access to CA).
>
> So no new backing files can be introduced by QEMU after it has started
> without libvirt knowing it?

No, you missed my point.  A new backing file can only be introduced by 
qemu after it has started by libvirt using a finite set of monitor 
commands.  These include disk hotplug (libvirt adds to the list of files 
known to be accessed by qemu, by reading the image headers of the new 
disk to be hot-plugged prior to issuing the monitor command), by disk 
hot-unplug (libvirt revokes the access to the files making up that disk, 
which it remembers from before the disk was added), and snapshot_blkdev 
(libvirt is explicitly requesting a new qcow2 file with the old file as 
the backing image, so it knows the new relationship of files to be 
accessed by that block device).  Since libvirt issued the monitor 
commands, libvirt always knows which files qemu should be trying to 
access when servicing those block devices to the guest.

>
> OK. I think fds would be useful internally in a privilege separation
> mode in plain QEMU too.

Yes, there's more than one reason to add fd support to all possible 
situations where qemu is currently resorting to open().

-- 
Eric Blake   eblake@redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org