[Libvir] [PATCH] virDomainMigrate version 4 (for discussion only!)

[Daniel Veillard]

On Tue, Jul 24, 2007 at 01:56:08AM +0100, Daniel P. Berrange wrote:
> On Wed, Jul 18, 2007 at 08:22:37PM +0100, Richard W.M. Jones wrote:
[...]
> I wonder where we should allow for multiple back-forth between prepare and
> perform. The 'perform' method could return a tri-state - success, failure
> or continue. In the latter case it would call prepare on the destination again
> before calling perform on the source a second time. eg you might end up with
> an exchange like
> 
>    1. --> client calls prepare at destination
>    2. <-- destination returns some metadata
>    3. --> client calls perform at source with metdata
>    4. <-- source returns 'continue'
>    5. --> client calls prepare are destination again
>    6. <-- destination returns more metdata
>    7. --> client calls perform at source with more metdata
>    8. <-- source returns 'success'
> 
> 
> In fact thinking about DV's suggestion that we should have a 'finalize'
> method at the destination. If we generalized just one step more we could
> handle this. Have just 2 methods
> 
>    virDrvDomainMigrateSource
>    virDrvDomainMigrateDestination
> 
> Both methods return a tri-state, 'complete', 'failed', 'continue'. The impl
> of virDomainMigrate starts with virDrvDomainMigrateDestination, then calls
> virDrvDomainMigrateSource, then calls virDrvDomainMigrateDestination again,
> and then virDrvDomainMigrateSource again, etc, etc. The sequence stops when
> both virDrvDomainMigrateSource & virDrvDomainMigrateDestination have returned
> 'complete', or one of them has returned 'failure'. 

  Interesting. This would mean we could implement a low level transfer
protocol within libvirt, bypassing the hypervisor own support :-)
  I still think you need a function which finalize and return the handle to
the new domain in a possibly atomic fashion. Calling a lookup introduces a
hazard IMHO it may fail even if the migration suceeded.

> Maybe this is all overkill, and hopefully, no impl would ever need more than a 
> single call to either method, but I'm worried that we're designing this wire
> level protocol with single exchange+cookie, based on a rough idea for a potential 
> future impl in Xen which has not actually been implemented yet. 
> 
> I think it could be a useful future-proofing to allow for the arbitrary back-and-
> forth at the wire level, could make use of it without needing to break client 
> <-> daemon compatability.
> 
> Alternatively, we could hold-off on adding a migrate API to libvirt, and get
> involved in upstream Xen to sort out secure migration for XenD. Then come back
> and finalize the libvirt design based on more knowledge of what we're going to
> be talking to.

  Let's be frank,  I wasn't thinking about a future Xen new migration impl.
I was thinking about the possibility to implement an in-libvirt migration
based on save/transfer/restore and being able to make this an atomic
transactional operation. That was the 2 kind of use I was thinking of.

  W.r.t. the protocol ABI I agree we should really be careful about it, 
I think we should just state that for migration, at this point we may not
have a stable protocol, and it may break in future release. I think that's
reasonnable at the moment.

  I would really like to make a new release today or tomorrow to try to 
push the version for testing in the Fedora 8 test 1 beta.

Daniel

-- 
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard      | virtualization library  http://libvirt.org/
veillard at redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine  http://rpmfind.net/