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@xxxxxxxxxx | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list