[Libvir] [PATCH] (for discussion only) KVM migration v1

[Daniel Veillard]

On Tue, Apr 08, 2008 at 07:54:01PM +0100, Richard W.M. Jones wrote:
> This patch implements KVM to KVM migration.  It is for discussion
> only, partly because it doesn't work for some reason I can't quite
> work out at the moment.
> 
> We implement a second version of the migration protocol.  This second
> version has two differences:
> 
> (1) Prepare step is replaced by Prepare2, which passes the domain XML.
> As explained previously this is required for KVM because we use this
> on the target host to recreate the precise qemu-kvm command line as on
> the source host.
> 
> (2) Finish step is replaced by Finish2.  There are two differences
> here: firstly Finish2 is always called on the destination host, even
> if the migration failed.  Secondly the return code from the migration
> (Perform step) is passed to Finish2.  This is required for KVM
> migration because if the migration failed we need to tear down the
> empty qemu shell, otherwise failed migrations could leave effectively
> zombie qemu processes around.
> 
> libvirt.c:virDomainMigrate function has been changed so that it can
> support either form of migration protocol, and the Xen driver
> continues to use version 1.  The changes here are pretty minor, and
> there are no changes to the Xen driver.
> 
> The additional code involves implementing Prepare2 / Finish2 in the
> remote protocol, and of course implementing migration in the qemu
> driver itself.
> 
> A final word about the parameters to virDomainMigrate.
> 
>  - flags is ignored.  All KVM migrations are "live", it doesn't matter
>    if you supply the live flag or not.
> 
>  - desturi may optionally be used to control the TCP port used for
>    migration.  If desturi is NULL then a TCP port is chosen at
>    random (or in future, some suitable secure method will be used
>    instead).  If desturi is set to "tcp://hostname:port" then the
>    given port number is used, and hostname is expected to be the
>    hostname or IP address of the target server.
> 
> You cannot do localhost->localhost migrations (even though this is
> supported by KVM) because libvirtd doesn't like you creating two VMs
> with the same UUID, even if only temporarily.  So to test this you
> really need two machines, or at least two instances of libvirtd
> configured not to stomp on each other.

  Hum, this looks fine to me except for one point, i don't see why we need
to add the v2 versions to the driver structure. Can't this be hidden behind
unified functions in the driver themselves ? Maybe i missed something though,

Daniel


-- 
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard      | virtualization library  http://libvirt.org/
veillard at redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine  http://rpmfind.net/