On Tue, Apr 12, 2011 at 05:12:18PM -0600, Eric Blake wrote: > 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? The source can already abort migration, even in the v2 protocol, using the virDomainJobAbort() API (or virsh domjobabort). This issues a 'migrate_cancel' monitor command to QEMU, which in turns causes the 'perform' step to return failure, which is passed to the 'finish' step which tears down the destination VM Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list