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