WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-api

Re: [Xen-API] Xen Management API draft

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