Re: A migration framework for external devices

[Anthony Liguori <aliguori@us.ibm.com>]

Stefan Berger wrote:
> The problem that I would see with a framework living outside XenD is 
> that you now have two different entities taking care of migration. 
> Certainly it should be one piece of code that does everything.
> I don't understand your argument about a push/pull migration model. I 
> mean in certain ways everything is push/pull and push is certainly 
> what we have today with a command like "xm migrate <DomID> <Host>", 
> which effectively pushes the vm onto another machine. What would be 
> different in the new model?
Sorry, I should have been more specific.  You still have an xm migrate 
<Dom> <Host> command, but instead of always having a daemon running on 
Host to receive the migration, it instead uses something like ssh to 
execute an "xm migrate-incoming <port>" command on the host.  Locally, 
you would use an "xm migrate-outgoing <Dom> <Host> <port>" command.

Since migration doesn't actually do anything when not migrating there's 
no point in just having an idle thread in Xend (or any idle daemon at 
all).  It also allows you to do clever things like vary the port which 
should add to the security of migration.
> Plug-ins  will need to exist in some form on another since knowledge 
> is needed about how to migarte a specific technology and prepare the 
> target system for it - and maybe check the target system first whether 
> that technology is supported there or migration requirements can be 
> met. In a way they do exist today with classes like 
> xen/xend/{pciif,netif,blkif,usbif,tpmif}.py which are all implementing 
> technology-specific code - not for migration, though.
Why do plugins have to exist?  The only reason to have a plugin 
mechanism is to be able to maintain plugins outside of the Xend tree 
which would require a stable plugin interface.  I don't think we're at a 
point where we can do that.
>
> > Is it static throughout the lifetime of the domain or does it change?  
>
> The TPM state itself is not static throughout the lifetime of a 
> domain. It does change - if that's what you mean.
>
> > How much state are we talking about migrating?
>
> It's not going to be much in terms of kilobytes or so, but it might 
> end up being the first device that lives outside a domain an needs to 
> be migrated.
How many round trips would it require?  If the data is dynamic, it has 
to be transferred (or at least finalized) during the final stage of 
migration which is performance critical.
> My gut feeling is that we need to design a flexible migration protocol 
> that is is extensibile. So I am just looking around what other poeple 
> think, although I am doing some coding as well :-).
This all sounds like it's going to add complexity.  The tools are 
already far too complex.

Regards,

Anthony Liguori
>    Stefan
>
> >
> > Regards,
> >
> > Anthony Liguori
> > > Clients on the source machine would communicate with that daemon and
> > > transfer the state. The clients would have to be triggered by XenD
> > > after a partition is not scheduled anymore and be given the IP 
> address
> > > of the target machine. Afterwards there needs to be some
> > > synchronization on resuming the scheduling on the target machine 
> after
> > > all state has been deserialized.
> > >   The plugable deamon itself would handle the communication 
> sockets, a
> > > low-level protocol which the plugins and clients would use, have
> > > support for timing and protocol time-outs and provide threading. The
> > > plugins would have to do the rest of what's necessary to communicate
> > > with the infrastructure and the higher-level protocol shared with the
> > > clients.
> > >   Comments?
> > >
> > >   Stefan
> > > 
> ------------------------------------------------------------------------
> > >
> > > _______________________________________________
> > > Xen-devel mailing list
> > > Xen-devel@lists.xensource.com
> > > http://lists.xensource.com/xen-devel
> > >  
> >