Re: [libvirt] RFC: APIs for managing a subset of a domain's disks
On Mon, May 02, 2011 at 05:31:00PM -0600, Eric Blake wrote:
Consider the case of a guest that has multiple virtual disks, some
residing on shared storage (such as the OS proper) and some on local
storage (scratch space, where the OS has faster response if the virtual
disk does not have to go over the network, and possibly one where the
guest can still work even if the disk is hot-unplugged). During
migration, you'd want different handling of the two disks (the
destination can already see the shared disk, but must either copy the
contents or recreate a blank scratch volume for the local disk).
I don't really see that use case being practical. Even if it is just
a scratch disk, I don't see how a guest OS/app can use the scratch
disk if the data can be arbitrarily reset under its feat without any
warning / notification.
Or, consider the case where a guest has one disk as qcow2 (it is not
modified frequently, and benefits from sharing a common backing file
with other guests), while another disk is raw (for better read-write
performance). Right now, 'virsh snapshot' fails, because it only works
if all disks are qcow2; and in fact it may be the case that it is
desirable to only take a snapshot of a subset of the domain's disks.
Snapshotting seems interesting, but I think the alternative design
for the snapshot API[1] which is disk based already copes with this
use case. eg, the
virDomainQuiesceStorage($dom)
foreach disk
virStorageVolCreate($volsnapshotxml);
virDomainUpdateDevice($dom, $diskxml);
virDomainUnquiesceStorage($dom);
So, I think we need some way to request an operation on a subset of
VM
disks, in a manner that can be shared between migration and volume
management APIs. And I'm not sure it makes sense to add two more
parameters to migration commands (an array of disks, and the size of
that array), nor to modify the snapshot XML to describe which disks
belong to the snapshot.
So I'm thinking we need some sort of API set to manage a stateful set of
disk operations. Maybe the trick is to define that every VM has a
(possibly empty) set of selected disks, with APIs to manage moving a
single disk in or out of the set, an API for listing the entire set,
then a single flag to migration that states that live block migration is
attempted for all disks currently in the VMs selected disk set.
I'm not really seeing a clear need for this API yet.
Regards,
Daniel
[1] http://www.redhat.com/archives/libvir-list/2011-January/msg00351.html
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|