From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Mike D. Day" Subject: Re: A migration framework for external devices Date: Thu, 09 Feb 2006 07:34:35 -0500 Message-ID: <43EB36DB.7080302@us.ibm.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Stefan Berger Cc: xen-devel@lists.xensource.com, "Cihula, Joseph" , Ronald Perez , "Scarlata, Vincent R" List-Id: xen-devel@lists.xenproject.org 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. Mike