On 02/09/2011 09:58 AM, Daniel P. Berrange wrote:
This patch attempts to introduce a version 3 that uses the improved 5 step sequence
* Src: Begin - Generate XML to pass to dst - Generate optional cookie to pass to dst
* Dst: Prepare - Get ready to accept incoming VM - Generate optional cookie to pass to src
* Src: Perform - Start migration and wait for send completion - Generate optional cookie to pass to dst
* Dst: Finish - Wait for recv completion and check status - Kill off VM if failed, resume if success - Generate optional cookie to pass to src
* Src: Confirm - Kill off VM if success, resume if failed
I've been thinking about this a bit more, and have a question. What happens when the source side decides to abort the migration? For example, if libvirtd on the source gets a SIGHUP or SIGINT, it would be nice to have the cleanup code abort any in-flight migrations so that when libvirtd is restarted, the guest is still operational on the source, and the guest does not have to wait for a full TCP timeout cycle to realize that the source is not going to complete the migration. Does this call for additional internal points in the RPC implementation of v3 migration? -- Eric Blake eblake@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org