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

Tue Jun 24 07:03:51 UTC 2014

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?

Peter
> +
> +<pre>
> +<emulatorCapabilities>
> +  <path>/usr/bin/qemu-system-x86_64</path>
> +  <domain>kvm</domain>
> +  <machine>pc-i440fx-2.1</machine>
> +  ...
> +</emulatorCapabilities>
> +</pre>
> +    <dl>
> +      <dt>path</dt>
> +      <dd>The full path to the emulator binary.</dd>
> +
> +      <dt>domain</dt>
> +      <dd>Describes the <a href="formatdomain.html#elements">virtualization
> +          type</a> (or so called domain type).</dd>
> +
> +      <dt>machine</dt>
> +      <dd>The domain's <a href="formatdomain.html#elementsOSBIOS">machine
> +          type</a>.</dd>
> +    </dl>
> +  </body>
> +</html>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20140624/6c994c67/attachment-0001.sig>