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?
(b) Does anyone see a simpler way to do this?
(c) Since we're adding a second version of the protocol, does anyone
  want anything else added?
(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).

Rich.

Notes:

[1] https://www.redhat.com/archives/libvir-list/2007-July/msg00357.html
and https://www.redhat.com/archives/libvir-list/2007-July/msg00304.html

[2] 
http://kvm.qumranet.com/kvmwiki/Migration#head-71900dbcf45d8ac81649fe4f031c5bb64602b066

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top

--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Reply via email to