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: Thu, 9 Feb 2006 11:20:38 -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 16:32:13 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <43EB36DB.7080302@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 07:34:35 AM:

> Stefan Berger wrote:
> >
> > It should be possible to do that as long as it is definable what 'good
> > state' means.
> Yes, good point. In this case the framework should not define policy,
> but the plugin should. In other words, the plugin could do whatever it
> wants to on the target, the framework only cares about the status
> returned by the plugin. If the plugin says "ok to proceed" then the
> migration continues.

Exactly. The framework itself should have no knowledge about the individual requirements of those technologies that need to be supported on the target system. It only would provide a communication channel, a socket to talk to on a system, and push all the intelligence into the plugins.

Also what the plugins would need to do is lock the system so that once the migration of VM A is starting no other migrated virtual machine B has altered the state into a contradictory state that prevents migration of A. I think one of the aspects of migration is to look at the target system first and see whether one can migrate into it, then lock it to its state (or do that at the same time) and then start the migration. Basically migration needs to be 'atomic'.

> >
> > Another question is whether an extensible protocol exists that could be
> > recycled for this purpose or we have to build something from ground up.
> Unfortunately the best thing I can think of is a protocol defined using
> xml. As you mentioned, this idea includes existing bulk transfer but
> adds event and procedural semantics. xml encodings are already defined
> for everything we need including bulk data transfers, event semantics,
> and remote procedure calls. However, I don't think we should use xml
> encodings for bulk data transfer. We could keep that part as it is now.

I would have let the plugins implement their own protocol that suits their needs and the framework just provides a lower level transport protocol for dispatching messages to the plugins. At least that was my initial thinking. Not sure whether RPC is necessary here.

> I don't think xml would dominate the migration protocol. We could use it
> for the plugin semantics and to control the important checkpoints in pre
> and post -migration phases. But the migration itself should be encoded
> in the existing file transfer protocol.

I mixture of binary and xml-based protocol would certainly be helpful.

> Mike

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
Xen-devel mailing list