Re: [libvirt] [PATCH 2/5] conf: Introduce viremulator_capabilities
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(a)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>
Attachments:
- signature.asc (application/pgp-signature — 901 bytes)