Re: [Xen-API] Xen Management API draft

[Stefan Berger <stefanb@xxxxxxxxxx>]

xen-api-bounces@xxxxxxxxxxxxxxxxxxx wrote on 06/26/2006
07:09:02 PM:

> Ewan Mellor wrote:
> > On Mon, Jun 26, 2006 at 06:36:22PM +0100, Daniel P. Berrange
wrote:
> >
> >   
> >>>> VM needs a migrate method:
> >>>>
> >>>> Bool migrate(session id s, vm ref vm, host ref current,
host ref
> >>>> destination, Bool test)
> >>>>         
> >>> D'oh!  We probably want a migrate command in there
;-)
> >>>       
> >> How would authentication operate - the destination host must
have some
> >> kind of  authentication process before accepting migration
of a VM from
> >> another host. So would this API assume that authentication
credentials
> >> have been previoously set up behind the scenes ? If not then
the migrate
> >> API would need some way to request / receive authenitcation
credentials.
> >>     
> >
> > How about this?
> >
> > /**
> >  * @returns authToken
> >  */ 
> > String vm_migrate_authorise(String session, String uuid)
> >
> > void vm_migrate(String session, String uuid, String destination,
> >                 String
authToken)
> >
> > So you log in to the destination and source as normal, and then
issue a
> > "migrate_authorise" to the destination, receive a token
which the 
> destination
> > has generated randomly, give that to the source, and then the
source passes
> > that authToken to the destination as part of the handshake on
the migration
> > channel (the connection that the actual memory contents go down).
> >
> > Does that sound OK?  This restricts the authentication exchange
tothe login
> > messages (however we want to do that) and then relies upon session
> tokens from
> > then on.
> >   
> 
> It seems there should be a mechanism for ensuring the target host
is 
> capable of hosting the VM as well.  Does the target host have
compatible 
> architecture, cpu flags (if that matters), hypervisor version, etc.?
 I 
> guess one could argue that clients should be responsible for ensuring
> the target is acceptable prior to performing the migration, particularly
> when one considers all of the things that could go wrong - e.g. some
> disk on the SAN that the VM requires is not available at the target.
 At 

The whole migration procedure should in the optimal
case be 'atomic'. One could allocate resources on the target system and
lock the allocation to ensure that no other system migrates a VM there
that makes your system perform worse on the target system than where it's
being migrated from.

> a minimum though the implementation should handle migration failures
> gracefully and not "lose" the VM, i.e. we start shoveling
pages over to 
> the target host and for whatever reason we are unable to bring the
thing 
> up there *and* it is no longer running on the source host.

I think Xend actually handles that case already.

> 
> Also, should we be concerned about migrating VMs across untrusted
> networks?  Should there be mechanisms to support encrypting the
memory?
> 
It would certainly be interesting to have this as
an option. You could use the passed-around authentication token from your
suggestion above to establish a shared key between the source and destination
system.

 Stefan

> Regards,
> Jim
> 
> _______________________________________________
> xen-api mailing list
> xen-api@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api
_______________________________________________
xen-api mailing list
xen-api@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api