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: Stefan Berger <stefanb@xxxxxxxxxx>
Subject: Re: [Xen-devel] A migration framework for external devices
From: "Mike D. Day" <ncmike@xxxxxxxxxx>
Date: Thu, 09 Feb 2006 07:34:35 -0500
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, "Cihula, Joseph" <joseph.cihula@xxxxxxxxx>, Ronald Perez <ronpz@xxxxxxxxxx>, "Scarlata, Vincent R" <vincent.r.scarlata@xxxxxxxxx>
Delivery-date: Thu, 09 Feb 2006 12:45:45 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <OFAF40C2ED.9A049C9A-ON8525710F.007C18EC-8525710F.007C8530@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>
References: <OFAF40C2ED.9A049C9A-ON8525710F.007C18EC-8525710F.007C8530@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 1.5 (Macintosh/20051201)
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.

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


Xen-devel mailing list