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 :|
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list