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: Ewan Mellor <ewan@xxxxxxxxxxxxx>
Subject: Re: [Xen-API] Xen Management API draft
From: Jim Fehlig <jfehlig@xxxxxxxxxx>
Date: Fri, 23 Jun 2006 17:48:08 -0600
Cc: Xen-API <xen-api@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Fri, 23 Jun 2006 16:48:32 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20060622170130.GI25606@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: <20060622170130.GI25606@xxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-api-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird (X11/20060516)
Ewan Mellor wrote:
Attached is a draft Xen Management API.  This document presents our ideas in
terms of a data model, with an implied binding to XML-RPC calls.  There are a
few examples in there too -- hopefully it's clear how the mapping between the
document and the wire protocol.

Thanks Ewan.

In particular, we need to get this API into a state so that it is the right
API for Xen-CIM.  We need to think whether libvirt is ready to rely upon this
API too.  That would mean moving the hypercalls and Xenstore reads and writes
out of libvirt, and pushing it up the stack alongside the other client-side

Is it realistic to use XML-RPC for tasks such as resource monitoring? Seems like there should be an optional, lower-latency, lighter-weight mechanism to retrieve things such as host_cpu.utilisation, VBD.IO_bandwidth/incoming_kbs, etc. (Makes me thing of Uncertainty Principle or Observer Effect, i.e. we crank up cpu utilization by asking for cpu utilization :-)). I guess the hypercalls and Xenstore reads/writes mentioned above would still exist but not be part of the "guarantees" for Xen.

Many of the RPCs return void, e.g. VM.start(), VM.pause(), etc. How are failures indicated? Via the Status and ErrorDescription elements of return value struct?


xen-api mailing list