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