Re: [Xen-API] Xen Management API draft

[Jim Fehlig <jfehlig@xxxxxxxxxx>]

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 to the 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 
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.
Also, should we be concerned about migrating VMs across untrusted 
networks?  Should there be mechanisms to support encrypting the memory?
Regards,
Jim

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