[Libvir] [PATCH] (for discussion only) KVM migration v1
veillard at redhat.com
Wed Apr 9 12:22:18 UTC 2008
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,
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/
More information about the libvir-list