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@xxxxxxxxxx | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list