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@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/