[libvirt] [PATCH 01/16] Introduce yet another migration version in API.

[Daniel P. Berrange]

On Wed, May 11, 2011 at 11:51:41AM +0200, Jiri Denemark wrote:
> On Wed, May 11, 2011 at 10:09:47 +0100, Daniel P. Berrange wrote:
> > The problems with this [migration v2] are:
> > 
> >  - Since the first step is a generic 'DumpXML' call, we can't
> >    add in other migration specific data. eg, we can't include
> >    any VM lease data from lock manager plugins
> >  - Since the first step is a generic 'DumpXML' call, we can't
> >    emit any 'migration begin' event on the source, or have
> >    any hook that runs right at the start of the process
> >  - Since there is no final step on the source, if the Finish
> >    method fails to receive all migration data & has to kill
> >    the VM, then there's no way to resume the original VM
> >    on the source
> 
> Sorry for not noticing it earlier but I think we have another problem with our
> current migration schema (and this v3 as well). Domain XML may contain some
> data (such as /domain/devices/graphics/@listen) that an application may wish
> to change when migrating a domain. What would be the best way to implement the
> ability to modify domain XML that is passed to target libvirtd? A callback
> parameter for virDomainMigrate API or something else perhaps?

Well there's several issues here. The immediate one is that the public
migration API doesn't provide any way to expose this kind of capaibility
to applications. The v3 migration code is providing a new internal
migration protocol, for our existing public migration API, so existing
migration usage will be unchanged from app dev POV.

I also don't much like the idea of allowing the application to make
arbitrary config changes at migration time. In particular it will make
it hard to provide any kind of meaningful fine grained access control
over migration, and hard to guarantee that things like disk locking
are consistent.

Our general goal has been that the XML should be designed such that
it does not rely on host specific config tasks. cf the work being
done for virtual network switches, so we can avoid directly refering
to host interface names for NIC config.

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