Re: [Xen-devel] A migration framework for external devices

[Stefan Berger <stefanb@xxxxxxxxxx>]

xen-devel-bounces@xxxxxxxxxxxxxxxxxxx wrote on 02/09/2006
12:05:46 PM:

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

I don't think that adds to security. How would you
find out the current port number if it's a moving target? You have to either
have a shared algorithm that calculates the current port number based on
some known parameters or you ask a daemon/lookup service where that port
currently is.

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

The transfer could happen in parallel of transferring
the last few (dirty) pages. I cannot say about the number of exchanges.

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

That goes hand-in-hand with added functionality.

   Stefan

> 
> 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@xxxxxxxxxxxxxxxxxxx
> > > > http://lists.xensource.com/xen-devel
> > > >  
> > >
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel