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