WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: aliguori@xxxxxxxxxx
Subject: Re: [Xen-devel] A migration framework for external devices
From: Stefan Berger <stefanb@xxxxxxxxxx>
Date: Thu, 9 Feb 2006 12:51:54 -0500
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, "Cihula, Joseph" <joseph.cihula@xxxxxxxxx>, Ronald Perez <ronpz@xxxxxxxxxx>, "Scarlata, Vincent R" <vincent.r.scarlata@xxxxxxxxx>, xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 09 Feb 2006 18:04:03 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <43EB766A.30701@xxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx

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