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

[Richard W.M. Jones]

Daniel P. Berrange 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'
[...]

I sense we're allowing this to grow into a private protocol between the 
source and destination.  In reality no current migration system that we 
support will use anything more than a single call to 
domainMigratePrepare followed by a single call to domainMigratePerform 
method.  (eg. for qemu, you need to start a listener at the destination, 
then at the source send a few console commands).  Xen only uses 
domainMigratePerform, but may possibly in future use a single call to 
domainMigratePrepare (but there isn't even code for this, nevermind 
acceptance from upstream).

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

Now this I totally agree with.

Rich.

-- 
Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
Street, Windsor, Berkshire, SL4 1TE, United Kingdom.  Registered in
England and Wales under Company Registration No. 03798903
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20070724/7bc16abf/attachment-0001.bin>