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
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
-- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list