[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-API] Xen Management API draft

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.


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



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.