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?
--
Eric Blake eblake(a)redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
Attachments:
- signature.asc (application/pgp-signature — 620 bytes)