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