[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Libvir] KVM migration



On Mon, Apr 07, 2008 at 11:58:24AM -0400, Daniel Veillard wrote:
> >   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.

The dname is used when you want to rename the domain during the
migration (if indeed this is supported - it isn't in Xen, it will be
in KVM).

So in most cases dname is actually NULL.

However ... the current Xen driver turns out to ignore the dname
during Prepare, but later on errors out if dname != NULL in the
Perform step.

Could that behaviour be used to make a backwards-compatible version I
wonder ...?  I think _not_ actually, but I'm not 100% sure.

> > (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.

Yes, we will use the SupportsFeature driver call to detect if
migration V2 is supported.  Xen will be changed to support both (very
simple change) and KVM will support only V2.  In either case, libvirt
will have to continue to support both styles in case it needs to talk
to old libvirtd's.

> > (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).

Rich.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into Xen guests.
http://et.redhat.com/~rjones/virt-p2v


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]