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@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/