Re: [libvirt] [PATCH 3/6] Introduce yet another migration version in API.

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?