[libvirt] RFC: APIs for managing a subset of a domain's disks

[Daniel P. Berrange]

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 :|