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/
Home Products Support Community News


Re: [Xen-API] Xen Management API draft

To: "Daniel P. Berrange" <berrange@xxxxxxxxxx>
Subject: Re: [Xen-API] Xen Management API draft
From: Ewan Mellor <ewan@xxxxxxxxxxxxx>
Date: Mon, 26 Jun 2006 19:03:55 +0100
Cc: Xen-API <xen-api@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Mon, 26 Jun 2006 11:04:02 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20060626173622.GI30083@xxxxxxxxxx>
List-help: <mailto:xen-api-request@lists.xensource.com?subject=help>
List-id: Discussion of API issues surrounding Xen <xen-api.lists.xensource.com>
List-post: <mailto:xen-api@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api>, <mailto:xen-api-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api>, <mailto:xen-api-request@lists.xensource.com?subject=unsubscribe>
References: <20060622170130.GI25606@xxxxxxxxxxxxxxxxxxxxxx> <449BEE61.1040401@xxxxxxxxxx> <20060626154643.GB10089@xxxxxxxxxxxxxxxxxxxxxx> <20060626173622.GI30083@xxxxxxxxxx>
Sender: xen-api-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.9i
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.


xen-api mailing list