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/
Home Products Support Community News


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

To: ncmike@xxxxxxxxxx
Subject: Re: [Xen-devel] A migration framework for external devices
From: Stefan Berger <stefanb@xxxxxxxxxx>
Date: Wed, 8 Feb 2006 17:40:08 -0500
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, "Cihula, Joseph" <joseph.cihula@xxxxxxxxx>, Ronald Perez <ronpz@xxxxxxxxxx>, "Scarlata, Vincent R" <vincent.r.scarlata@xxxxxxxxx>
Delivery-date: Wed, 08 Feb 2006 22:51:42 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <43EA7167.7000208@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

ncmike@xxxxxxxxxxxxxxxxxxxxxxx wrote on 02/08/2006 05:32:07 PM:

> Stefan Berger wrote:
> >>>  To be a bit clearer on the idea of the framework: It would consist of
> > a
> >>> deamon running on the target machine whose different plug-ins know how
> > to
> >>> handle the migration of different pieces of state information and know
> > how
> >>> to de-serialize them (which mere 'scp' would not do).
> >> So an underlying assumption would be that the local and remove real or
> >> virtual devices support serialize/deserialize of state, correct?
> >
> > Yes, that's correct.
> Would also  be very cool if the framework had pre-migration hooks. For
> example, allow someone to write a plugin to verify that the target host
> is qualified and in a good state to accept a migration  before it
> actually starts.

It should be possible to do that as long as it is definable what 'good state' means.
> Also, some physical devices may need to be configured/re-configured on
> the target prior to a migration (infiniband, fiber channel, iscsi) and
> it would be good to have plugins for that as well.

Again, this also sounds good to me.

Another question is whether an extensible protocol exists that could be recycled for this purpose or we have to build something from ground up.


> Mike
Xen-devel mailing list