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

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



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


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