[libvirt] [PATCH 2/5] conf: Introduce viremulator_capabilities

Tue Jun 24 09:39:07 UTC 2014

On Tue, Jun 24, 2014 at 09:03:51AM +0200, Peter Krempa wrote:
> On 06/20/14 16:19, Michal Privoznik wrote:
> > The virEmulatorCapabilities is going to hold emulator capabilities,
> > surprisingly. It's intended to be able to cover qemuCaps, lxcCaps
> > (once we invent them, if ever) and so on. Among with adding the code
> > itself, both some documentation and basic testing is introduced too.
> > 
> > Signed-off-by: Michal Privoznik <mprivozn at redhat.com>
> > ---
> 
> ...
> 
> > 
> > diff --git a/docs/formatemulatorcaps.html.in b/docs/formatemulatorcaps.html.in
> > new file mode 100644
> > index 0000000..beea1a9
> > --- /dev/null
> > +++ b/docs/formatemulatorcaps.html.in
> > @@ -0,0 +1,52 @@
> > +<?xml version="1.0" encoding="UTF-8"?>
> > +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
> > +<html xmlns="http://www.w3.org/1999/xhtml">
> > +  <body>
> > +    <h1>Emulator capabilities XML format</h1>
> > +
> > +    <ul id="toc"></ul>
> > +
> > +    <h2><a name="Motivation">Motivation</a></h2>
> > +
> > +    <p>Sometimes, when a new domain is to be created it may come handy to know
> > +    the capabilities of the hypervisor so the correct combination of devices and
> > +    drivers is used. For example, when management application is considering the
> > +    mode for a host device's passthrough there are several options depending not
> > +    only on host, but on hypervisor in question too. If the hypervisor is qemu
> > +    then it needs to be more recent to support VFIO, while legacy KVM is
> > +    achievable just fine with older one.</p>
> > +
> > +    <p>The main difference between <a
> > +        href="formatcaps.html">virConnectGetCapabilities</a> and the emulator
> > +    capabilities API is, the former one aims more on the host capabilities (e.g.
> > +    NUMA topology, security models in effect, etc.) while the latter one
> > +    specializes on the hypervisor capabilities.</p>
> > +
> > +    <h2><a name="elements">Element and attribute overview</a></h2>
> > +
> > +    <p>The root element that emulator capability XML document starts with has
> > +    name <code>emulatorCapabilities</code>. It contains at least three direct
> > +    child elements:</p>
> 
> We also have a <features> subelement of <guest> in the <capabilities>
> XML which is used for a similar thing although it doesn't support a
> per-machine-type output, only per-binary capabilities. Should we add
> this more granular approach and abandon the old one?

Yes, we should stop adding stuff related to the guest to the main
<capabilities> XML since it doesn't scale.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|