[Libvir] just a question about libvirt evolution

[Daniel P. Berrange]

On Thu, Jul 20, 2006 at 05:27:47PM +0200, Philippe Berthault wrote:
> Hello,
> 
> Several major modifications will appear this year in future Xen releases 
> (3.0.3 and 3.0.4) that may have impacts on libvirt. These modifications 
> (see xen roadmap edited by Ian Pratt in july 2006) are :
> - Introduction of XML-RPC,
> - Xen configuration files in XML format,
> - Suppression of S-Expressions,
> - etc..
> 
> What is the libvirt position about these points ?

When XenD supports XML-RPC we'll definitely be creating another driver
in libvirt to support the XML-RPC apis. We will also keep the existing
drivers which talk SEXPR, since we need libvirt to be usable against
older 3.0.1 and 3.0.2 versionf of Xen. None of this should be too
difficult since DV anticipated these kind of changes when libvirt was 
designed

> Is the initial goal of libvirt to mask Xen evolutions will be always 
> possible ?

Yes, a core goal of libvirt is to isolate the applications from instability
& changes in the upstream Xen APIs. So the application should not notice any 
difference when libvit is talking SEXPR to XenD, vs talking XML-RPC.

The new XML-RPC api, however, will introduce new capabilities which were
not possible with older SEXPR apis. For example, it will allow us to
authenticate with XenD over the HTTP connection. So we might gainthe
ability to manage a Xen box remotely - there is no authentication
support with SEXPR so this will never be possible with old API.

So, in summary we maintain backwards-compatability - an app using libvirt
against xen-3.0.2 should work unchanged on xen-3.0.3 or later. Going in
the other direction may-or-may not be possible depending on whether your
app is using any of the features new in 3.0.3

> The most problematic problem would be the configurations files in XML 
> format. Libvirt already supports its own XML format of configuration 
> files. It seems to me that it would be interesting to use the same XML 
> format (or a compatible format) in libvirt and in Xen. Is there a plan 
> in this direction ?

The important thing to note is that the Xen XML format will contain *huge*
amounts of information, much of which is very specific to Xen. libVirt is
intended to be Hypervisor agnostic, so there is information in the Xen XML
which will not neccessarily be made available via the libvirt XML. The
information exposed with libvirt ought to be sufficient for the vast majority
of high level management tools.

It would be desirable if there was compatability between the XML formats.
One way would be to define libvirt XML as the 'core data set' and then
the Xen specific bits could be added as elements as tags in a separate 
'<xen:...>' XML namespace.

If this doesn't happen, I imagine it would be fairly straightforward to
provide an XSLT stylesheet which tranlates between the two formats - libvirt
would be doing this internally anyway.

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