On Mon, Apr 07, 2008 at 04:40:41PM +0100, Richard W.M. Jones wrote: > It turns out that the general migration strategy I defined[1] in > reference to Xen, ie. the 3 steps of Prepare/Perform/Finish, isn't > sufficient to support KVM migration. > > The problem is that the destination needs to start qemu-kvm with > pretty much the exact same configuration / command line parameters as > were used at the source[2]. eg. If the source qemu-kvm has 512 MB of > RAM, then the destination had better have exactly 512 MB of RAM also. > (This is not the same as Xen where the migration protocol itself > carries this information between the two xend daemons). > > We can modify the Prepare step to pass this information -- I'm > suggesting that we just pass the domain XML of the source domain. > Thus the Prepare step would change from: > > static int > qemudDomainMigratePrepare (virConnectPtr dconn, > char **cookie, > int *cookielen, > const char *uri_in, > char **uri_out, > unsigned long flags, > const char *dname, > unsigned long resource) > > to: > > static int > qemudDomainMigratePreparev2 (virConnectPtr dconn, > char **cookie, > int *cookielen, > const char *uri_in, > char **uri_out, > + const char *dom_xml, > unsigned long flags, > const char *dname, > unsigned long resource) > > As hinted there, we also need a new version of the migration protocol, > and a new remote call (Preparev2). > > So questions: > > (a) Does anyone have any objections? Not really but i wonder if we can't hack some backward compatible implementation. Basically if you pass the XML you don't need to pass the dname domain name. And on an older implementation if receiving XML on a domain name if properly checked you should error out early on the receiving end allowing to retry the Prepare step with just the name. > (b) Does anyone see a simpler way to do this? Actually passing the XML is the simplest since you send all the informations What concerns me is to try to keep old and new versions to still communicate okay. maybe the Preparev2/Prepare allows already the do this when falling back if the receiving end has no Preparev2. > (c) Since we're adding a second version of the protocol, does anyone > want anything else added? Never need a v3 ;-) > (d) Will the domain XML alone be sufficient to recreate the exact > qemu command line? (Seems to be the case, and in fact KVM suspend/ > restore support seems to implicitly rely on this too). 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