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

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

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.