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

[Stefan Berger <stefanb@xxxxxxxxxx>]

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.

  Stefan
> 
> Mike
> 

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