Re: [libvirt] [PATCH] Introduce yet another migration version in API.
On 11/02/2010 07:08 AM, Daniel P. Berrange wrote:
Migration just seems togo from bad to worse. We already had to
introduce a second migration protocol when adding the QEMU driver,
since the one from Xen was insufficiently flexible to cope with
passing the data the QEMU driver required.
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
Are we any closer to implementing this new migration protocol?
Meanwhile, I just came up with a question - how does live migration
interact with transient changes? For example, consider Osier's recent
patches for things like virDomainIsUpdated which tracks whether a
running guest has had transient changes that should be tracked as long
as the guest runs, but which should not impact the persistent xml
definition of the guest when it stops and is restarted. Does that mean
that live migration has to send two XML definitions over the wire, for
both the persistent definition (to be used if the guest is stopped and
restarted) as well as the transient definition (to accurately reflect
the running state of the guest, including currently hot-plugged
devices)? Does this protocol accurately allow for the transfer of two
differing XML descriptions associated with a single running domain?
--
Eric Blake eblake(a)redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
Attachments:
- signature.asc (application/pgp-signature — 619 bytes)