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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxx    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list

[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]