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

To: Ewan Mellor <ewan@xxxxxxxxxxxxx>
Subject: Re: [Xen-API] Xen Management API draft
From: "Daniel P. Berrange" <berrange@xxxxxxxxxx>
Date: Mon, 26 Jun 2006 18:24:25 +0100
Cc: Xen-API <xen-api@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Mon, 26 Jun 2006 10:24:40 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20060626155433.GD10089@xxxxxxxxxxxxxxxxxxxxxx>
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: <20060625154903.GC30399@xxxxxxxxxx> <20060626155433.GD10089@xxxxxxxxxxxxxxxxxxxxxx>
Reply-to: "Daniel P. Berrange" <berrange@xxxxxxxxxx>
Sender: xen-api-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.4.1i
On Mon, Jun 26, 2006 at 04:54:33PM +0100, Ewan Mellor wrote:
> On Sun, Jun 25, 2006 at 04:49:03PM +0100, Daniel P. Berrange wrote:
> 
> > Finally, a higher level question - the API is still basically 
> > unidirectional,
> > poll based model. By this I mean, if I want to detect changes in a guest VMs
> > lifecycle state (eg, from running -> paused), then I have no choice but to
> > poll the 'power_state' field on every VM i'm interested in. If the app using
> > the API is a GUI app, then this polling is going to have to be done pretty
> > frequently (once per second or more) to provide an acceptable refresh in 
> > the 
> > UI. I'm concerned that polling so frequently over an HTTP / XML-RPC protocol
> > is going to impose a very significant performance hit on the host machine.
> > It would be very desriable if there was a formal API for getting 
> > asynchronous
> > callbacks notifying the client of changes in a VM's lifecycle state. I know
> > this is not really possible with XML-RPC, but I wanted to bring it up as a
> > use-case none-the-less in case there are alternate ways to provide such a
> > capability. 
> > 
> > The same issue is true of the proposed mechanism for asynchronous invocation
> > invocation of APIs - it also requires the client to make requests polling
> > for completion of the API which is not really buying any performance 
> > benefit.
> > Unless the client actually wanted the 'estimated time of completion' data,
> > they might as well just send a regular synchronous request & use select()
> > or poll() system calls on the HTTP socket to do a non-blocking wait for 
> > completion client side.
> 
> Here's a thought -- how about we provide a call with the semantics of "please
> give me the next event", which blocks at the server until an event becomes
> available.  The client would call the server with registration for events, and
> then make this synchronous call in another thread or in a select() loop, which
> would block until an event arrives.  If the connection gets broken without an
> event, just reconnect and block again.
> 
> Would this work?

That's an interesting idea, avoiding polling since the client can just watch
the socket in a select() / poll() call. It would obviously require keeping
a 2nd connection open to the hypervisor, however, that's not too onerous so
it's certainly a plausible solution even if it is a bit of a nasty hack.

Regards,
Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 

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