10:31 a.m.
After my RFC round, here are the actual patches.
Michal Privoznik (8):
Introduce domain_capabilities
Introduce virConnectGetDomainCapabilities
virsh: expose virConnectGetDomainCapabilities
tests: Move qemu caps XML parsing into shared unit
qemu_capabilities: Introduce virQEMUCapsCacheLookupByArch
qemu_capabilities: Introduce virQEMUCapsIsMachineSupported
qemu_capabilities: Introduce virQEMUCapsGetDefaultMachine
qemu: Implement virConnectGetDomainCapabilities
docs/formatdomaincaps.html.in | 200 ++++++++++++++++
docs/schemas/Makefile.am | 1 +
docs/schemas/domaincaps.rng | 90 ++++++++
docs/sitemap.html.in | 4 +
include/libvirt/libvirt.h.in | 7 +
libvirt.spec.in | 1 +
mingw-libvirt.spec.in | 2 +
po/POTFILES.in | 1 +
src/Makefile.am | 1 +
src/conf/domain_capabilities.c | 254 +++++++++++++++++++++
src/conf/domain_capabilities.h | 103 +++++++++
src/driver.h | 9 +
src/libvirt.c | 52 +++++
src/libvirt_private.syms | 8 +
src/libvirt_public.syms | 5 +
src/qemu/qemu_capabilities.c | 146 ++++++++++++
src/qemu/qemu_capabilities.h | 11 +
src/qemu/qemu_driver.c | 101 ++++++++
src/remote/remote_driver.c | 1 +
src/remote/remote_protocol.x | 19 +-
src/remote_protocol-structs | 11 +
tests/Makefile.am | 13 ++
tests/domaincapsschemadata/domaincaps-basic.xml | 10 +
tests/domaincapsschemadata/domaincaps-full.xml | 56 +++++
.../domaincaps-qemu_1.6.50-1.xml | 44 ++++
tests/domaincapsschematest | 11 +
tests/domaincapstest.c | 194 ++++++++++++++++
tests/qemucapabilitiestest.c | 57 +----
tests/testutilsqemu.c | 49 ++++
tests/testutilsqemu.h | 3 +
tools/virsh-host.c | 84 +++++++
tools/virsh.pod | 16 ++
32 files changed, 1509 insertions(+), 55 deletions(-)
create mode 100644 docs/formatdomaincaps.html.in
create mode 100644 docs/schemas/domaincaps.rng
create mode 100644 src/conf/domain_capabilities.c
create mode 100644 src/conf/domain_capabilities.h
create mode 100644 tests/domaincapsschemadata/domaincaps-basic.xml
create mode 100644 tests/domaincapsschemadata/domaincaps-full.xml
create mode 100644 tests/domaincapsschemadata/domaincaps-qemu_1.6.50-1.xml
create mode 100755 tests/domaincapsschematest
create mode 100644 tests/domaincapstest.c
--
1.8.5.5
10:31 a.m.
New subject: [libvirt] [PATCH for 1.2.7 1/8] Introduce domain_capabilities
This new module holds and formats capabilities for emulator. If you
are about to create a new domain, you may want to know what is the
host or hypervisor capable of. To make sure we don't regress on the
XML, the formatting is not something left for each driver to
implement, rather there's general format function.
The domain capabilities is a lockable object (even though the locking
is not necessary yet) which uses reference counter.
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
---
docs/formatdomaincaps.html.in | 200 +++++++++++++++++++
docs/schemas/Makefile.am | 1 +
docs/schemas/domaincaps.rng | 90 +++++++++
docs/sitemap.html.in | 4 +
libvirt.spec.in | 1 +
mingw-libvirt.spec.in | 2 +
po/POTFILES.in | 1 +
src/Makefile.am | 1 +
src/conf/domain_capabilities.c | 254 ++++++++++++++++++++++++
src/conf/domain_capabilities.h | 103 ++++++++++
src/libvirt_private.syms | 7 +
tests/Makefile.am | 8 +
tests/domaincapsschemadata/domaincaps-basic.xml | 10 +
tests/domaincapsschemadata/domaincaps-full.xml | 56 ++++++
tests/domaincapsschematest | 11 +
tests/domaincapstest.c | 149 ++++++++++++++
16 files changed, 898 insertions(+)
create mode 100644 docs/formatdomaincaps.html.in
create mode 100644 docs/schemas/domaincaps.rng
create mode 100644 src/conf/domain_capabilities.c
create mode 100644 src/conf/domain_capabilities.h
create mode 100644 tests/domaincapsschemadata/domaincaps-basic.xml
create mode 100644 tests/domaincapsschemadata/domaincaps-full.xml
create mode 100755 tests/domaincapsschematest
create mode 100644 tests/domaincapstest.c
diff --git a/docs/formatdomaincaps.html.in b/docs/formatdomaincaps.html.in
new file mode 100644
index 0000000..cfd61d9
--- /dev/null
+++ b/docs/formatdomaincaps.html.in
@@ -0,0 +1,200 @@
+<?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>Domain 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>domainCapabilities</code>. It contains at least four direct
+ child elements:</p>
+
+<pre>
+<domainCapabilities>
+ <path>/usr/bin/qemu-system-x86_64</path>
+ <domain>kvm</domain>
+ <machine>pc-i440fx-2.1</machine>
+ <arch>x86_64</arch>
+ ...
+</domainCapabilities>
+</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>
+
+ <dt>arch</dt>
+ <dd>The domain's <a
href="formatdomain.html#elementsOSBIOS">
+ architecture</a>.</dd>
+
+ </dl>
+
+ <h3><a name="elementsCPUAllocation">CPU
Allocation</a></h3>
+
+<pre>
+<domainCapabilities>
+ ...
+ <vcpu max='255'/>
+ ...
+</domainCapabilities>
+</pre>
+
+ <dl>
+ <dt>vcpu</dt>
+ <dd>The maximum number of supported virtual CPUs</dd>
+ </dl>
+
+ <h3><a name="elementsDevices">Devices</a></h3>
+
+ <p>
+ The final set of XML elements are all used to describe supported devices
+ and their capabilities. All devices occur as children of the main
+ <code>devices</code> element.
+ </p>
+
+<pre>
+<domainCapabilities>
+ ...
+ <devices>
+ <disk supported='yes'>
+ <enum name='diskDevice'>
+ <value>disk</value>
+ <value>cdrom</value>
+ <value>floppy</value>
+ <value>lun</value>
+ </enum>
+ ...
+ </disk>
+ <hostdev supported='no'/>
+ </devices>
+</domainCapabilities>
+</pre>
+
+ <p>All reported capabilities share the way that they are expressed. In the
+ example above we can see what disk devices are supported
(<code>disk</code>,
+ <code>cdrom</code>, <code>floppy</code> and
<code>lun</code>).</p>
+
+ <h4><a name="elementsDisks">Hard drives, floppy disks,
CDROMs</a></h4>
+ <p>Disk capabilities are exposed under <code>disk</code> element.
For
+ instance:</p>
+
+<pre>
+<domainCapabilities>
+ ...
+ <devices>
+ <disk supported='yes'>
+ <enum name='diskDevice'>
+ <value>disk</value>
+ <value>cdrom</value>
+ <value>floppy</value>
+ <value>lun</value>
+ </enum>
+ <enum name='bus'>
+ <value>ide</value>
+ <value>fdc</value>
+ <value>scsi</value>
+ <value>virtio</value>
+ <value>xen</value>
+ <value>usb</value>
+ <value>uml</value>
+ <value>sata</value>
+ <value>sd</value>
+ </enum>
+ </disk>
+ ...
+ </devices>
+</domainCapabilities>
+</pre>
+
+ <dl>
+ <dt>diskDevice</dt>
+ <dd>What disk types are supported.</dd>
+
+ <dt>bus</dt>
+ <dd>The bus within a domain that disk may occur on</dd>
+ </dl>
+
+ <h4><a name="elementsHostDev">Host device
assignment</a></h4>
+ <p>Some host devices can be passed through to a guest (e.g. USB, PCI and
+ SCSI). Well, only if the following is enabled:</p>
+
+<pre>
+<domainCapabilities>
+ ...
+ <devices>
+ <hostdev supported='yes'>
+ <enum name='mode'>
+ <value>subsystem</value>
+ <value>capabilities</value>
+ </enum>
+ <enum name='startupPolicy'>
+ <value>default</value>
+ <value>mandatory</value>
+ <value>requisite</value>
+ <value>optional</value>
+ </enum>
+ <enum name='subsysType'>
+ <value>usb</value>
+ <value>pci</value>
+ <value>scsi</value>
+ </enum>
+ <enum name='capsType'>
+ <value>storage</value>
+ <value>misc</value>
+ <value>net</value>
+ </enum>
+ <enum name='pciBackend'>
+ <value>default</value>
+ <value>kvm</value>
+ <value>vfio</value>
+ <value>xen</value>
+ </enum>
+ </hostdev>
+ </devices>
+</domainCapabilities>
+</pre>
+
+ <dl>
+ <dt>mode</dt>
+ <dd>Describes what passthrough modes are supported</dd>
+
+ <dt>startupPolicy</dt>
+ <dd>What startup policy modes are known to libvirt</dd>
+
+ <dt>subsysType</dt>
+ <dd>Enumerates subsystems that are capable of passing through a
device</dd>
+
+ <dt>capsType</dt>
+ <dd>host device mode</dd>
+
+ <dt>pciBackend</dt>
+ <dd>Which backend should be used to manage device passthrough</dd>
+ </dl>
+ </body>
+</html>
diff --git a/docs/schemas/Makefile.am b/docs/schemas/Makefile.am
index d71c327..0e14dc6 100644
--- a/docs/schemas/Makefile.am
+++ b/docs/schemas/Makefile.am
@@ -19,6 +19,7 @@ schema_DATA = \
basictypes.rng \
capability.rng \
domain.rng \
+ domaincaps.rng \
domaincommon.rng \
domainsnapshot.rng \
interface.rng \
diff --git a/docs/schemas/domaincaps.rng b/docs/schemas/domaincaps.rng
new file mode 100644
index 0000000..627b699
--- /dev/null
+++ b/docs/schemas/domaincaps.rng
@@ -0,0 +1,90 @@
+<?xml version="1.0"?>
+<!-- A Relax NG schema for the libvirt domain capabilities XML format -->
+<grammar xmlns="http://relaxng.org/ns/structure/1.0"
datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes">
+ <include href='basictypes.rng'/>
+ <start>
+ <ref name='domainCapabilities'/>
+ </start>
+
+
+ <define name='domainCapabilities'>
+ <element name='domainCapabilities'>
+ <interleave>
+ <element name='path'>
+ <ref name="absFilePath"/>
+ </element>
+ <element name='domain'>
+ <text/>
+ </element>
+ <element name='machine'>
+ <text/>
+ </element>
+ <element name='arch'>
+ <text/>
+ </element>
+ <optional>
+ <ref name='vcpu'/>
+ </optional>
+ <optional>
+ <ref name='devices'/>
+ </optional>
+ </interleave>
+ </element>
+ </define>
+
+ <define name='vcpu'>
+ <element name='vcpu'>
+ <attribute name='max'>
+ <ref name='unsignedInt'/>
+ </attribute>
+ <empty/>
+ </element>
+ </define>
+
+ <define name='devices'>
+ <element name='devices'>
+ <interleave>
+ <ref name='disk'/>
+ <ref name='hostdev'/>
+ </interleave>
+ </element>
+ </define>
+
+ <define name='disk'>
+ <element name='disk'>
+ <ref name='supported'/>
+ <ref name='enum'/>
+ </element>
+ </define>
+
+ <define name='hostdev'>
+ <element name='hostdev'>
+ <ref name='supported'/>
+ <ref name='enum'/>
+ </element>
+ </define>
+
+ <define name='supported'>
+ <attribute name='supported'>
+ <choice>
+ <value>yes</value>
+ <value>no</value>
+ </choice>
+ </attribute>
+ </define>
+
+ <define name='enum'>
+ <zeroOrMore>
+ <element name='enum'>
+ <attribute name='name'>
+ <text/>
+ </attribute>
+ <zeroOrMore>
+ <element name='value'>
+ <text/>
+ </element>
+ </zeroOrMore>
+ </element>
+ </zeroOrMore>
+ </define>
+</grammar>
diff --git a/docs/sitemap.html.in b/docs/sitemap.html.in
index 78e84e3..1e91869 100644
--- a/docs/sitemap.html.in
+++ b/docs/sitemap.html.in
@@ -175,6 +175,10 @@
<span>The driver capabilities XML format</span>
</li>
<li>
+ <a href="formatdomaincaps.html">Domain
capabilities</a>
+ <span>The domain capabilities XML format</span>
+ </li>
+ <li>
<a href="formatnode.html">Node Devices</a>
<span>The host device XML format</span>
</li>
diff --git a/libvirt.spec.in b/libvirt.spec.in
index 2ec7eed..f0bf737 100644
--- a/libvirt.spec.in
+++ b/libvirt.spec.in
@@ -2164,6 +2164,7 @@ exit 0
%{_datadir}/libvirt/schemas/basictypes.rng
%{_datadir}/libvirt/schemas/capability.rng
%{_datadir}/libvirt/schemas/domain.rng
+%{_datadir}/libvirt/schemas/domaincaps.rng
%{_datadir}/libvirt/schemas/domaincommon.rng
%{_datadir}/libvirt/schemas/domainsnapshot.rng
%{_datadir}/libvirt/schemas/interface.rng
diff --git a/mingw-libvirt.spec.in b/mingw-libvirt.spec.in
index 91c2dc2..a555f9c 100644
--- a/mingw-libvirt.spec.in
+++ b/mingw-libvirt.spec.in
@@ -205,6 +205,7 @@ rm -rf $RPM_BUILD_ROOT%{mingw64_libexecdir}/libvirt-guests.sh
%{mingw32_datadir}/libvirt/schemas/basictypes.rng
%{mingw32_datadir}/libvirt/schemas/capability.rng
%{mingw32_datadir}/libvirt/schemas/domain.rng
+%{mingw32_datadir}/libvirt/schemas/domaincaps.rng
%{mingw32_datadir}/libvirt/schemas/domaincommon.rng
%{mingw32_datadir}/libvirt/schemas/domainsnapshot.rng
%{mingw32_datadir}/libvirt/schemas/interface.rng
@@ -265,6 +266,7 @@ rm -rf $RPM_BUILD_ROOT%{mingw64_libexecdir}/libvirt-guests.sh
%{mingw64_datadir}/libvirt/schemas/basictypes.rng
%{mingw64_datadir}/libvirt/schemas/capability.rng
%{mingw64_datadir}/libvirt/schemas/domain.rng
+%{mingw64_datadir}/libvirt/schemas/domaincaps.rng
%{mingw64_datadir}/libvirt/schemas/domaincommon.rng
%{mingw64_datadir}/libvirt/schemas/domainsnapshot.rng
%{mingw64_datadir}/libvirt/schemas/interface.rng
diff --git a/po/POTFILES.in b/po/POTFILES.in
index 31a8381..70fb6c2 100644
--- a/po/POTFILES.in
+++ b/po/POTFILES.in
@@ -16,6 +16,7 @@ src/conf/capabilities.c
src/conf/cpu_conf.c
src/conf/device_conf.c
src/conf/domain_addr.c
+src/conf/domain_capabilities.c
src/conf/domain_conf.c
src/conf/domain_event.c
src/conf/interface_conf.c
diff --git a/src/Makefile.am b/src/Makefile.am
index 2b9ac61..e81af0c 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -248,6 +248,7 @@ NETDEV_CONF_SOURCES = \
DOMAIN_CONF_SOURCES = \
conf/capabilities.c conf/capabilities.h \
conf/domain_addr.c conf/domain_addr.h \
+ conf/domain_capabilities.c conf/domain_capabilities.h \
conf/domain_conf.c conf/domain_conf.h \
conf/domain_audit.c conf/domain_audit.h \
conf/domain_nwfilter.c conf/domain_nwfilter.h \
diff --git a/src/conf/domain_capabilities.c b/src/conf/domain_capabilities.c
new file mode 100644
index 0000000..df190eb
--- /dev/null
+++ b/src/conf/domain_capabilities.c
@@ -0,0 +1,254 @@
+/*
+ * domain_capabilities.c: domain capabilities XML processing
+ *
+ * Copyright (C) 2014 Red Hat, Inc.
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library. If not, see
+ * <http://www.gnu.org/licenses/>;.
+ *
+ * Author: Michal Privoznik <mprivozn(a)redhat.com>
+ */
+
+#include <config.h>
+
+#include "domain_capabilities.h"
+#include "domain_conf.h"
+#include "viralloc.h"
+#include "virstring.h"
+
+#define VIR_FROM_THIS VIR_FROM_CAPABILITIES
+
+static virClassPtr virDomainCapsClass;
+
+static void virDomainCapsDispose(void *obj);
+
+static int virDomainCapsOnceInit(void)
+{
+ if (!(virDomainCapsClass = virClassNew(virClassForObjectLockable(),
+ "virDomainCapsClass",
+ sizeof(virDomainCaps),
+ virDomainCapsDispose)))
+ return -1;
+ return 0;
+}
+
+
+VIR_ONCE_GLOBAL_INIT(virDomainCaps)
+
+
+static void
+virDomainCapsDispose(void *obj)
+{
+ virDomainCapsPtr caps = obj;
+
+ VIR_FREE(caps->path);
+ VIR_FREE(caps->machine);
+}
+
+
+virDomainCapsPtr
+virDomainCapsNew(const char *path,
+ const char *machine,
+ virArch arch,
+ virDomainVirtType virttype)
+{
+ virDomainCapsPtr caps = NULL;
+
+ if (virDomainCapsInitialize() < 0)
+ return NULL;
+
+ if (!(caps = virObjectLockableNew(virDomainCapsClass)))
+ return NULL;
+
+ if (VIR_STRDUP(caps->path, path) < 0 ||
+ VIR_STRDUP(caps->machine, machine) < 0)
+ goto error;
+ caps->arch = arch;
+ caps->virttype = virttype;
+
+ return caps;
+ error:
+ virObjectUnref(caps);
+ return NULL;
+}
+
+
+int
+virDomainCapsEnumSet(virDomainCapsEnumPtr capsEnum,
+ const char *capsEnumName,
+ size_t nvalues,
+ unsigned int *values)
+{
+ int ret = -1;
+ size_t i;
+
+ for (i = 0; i < nvalues; i++) {
+ unsigned int val = 1 << values[i];
+
+ if (!val) {
+ /* Integer overflow */
+ virReportError(VIR_ERR_INTERNAL_ERROR,
+ _("integer overflow on %s. Please contact the "
+ "libvirt development team at
libvir-list(a)redhat.com"),
+ capsEnumName);
+ goto cleanup;
+ }
+
+ capsEnum->values |= val;
+ }
+
+ ret = 0;
+ cleanup:
+ return ret;
+}
+
+
+void
+virDomainCapsEnumClear(virDomainCapsEnumPtr capsEnum)
+{
+ capsEnum->values = 0;
+}
+
+
+static int
+virDomainCapsEnumFormat(virBufferPtr buf,
+ virDomainCapsEnumPtr capsEnum,
+ const char *capsEnumName,
+ virDomainCapsValToStr valToStr)
+{
+ int ret = -1;
+ size_t i;
+
+ virBufferAsprintf(buf, "<enum name='%s'", capsEnumName);
+ if (!capsEnum->values) {
+ virBufferAddLit(buf, "/>\n");
+ ret = 0;
+ goto cleanup;
+ }
+ virBufferAddLit(buf, ">\n");
+ virBufferAdjustIndent(buf, 2);
+
+ for (i = 0; i < sizeof(capsEnum->values) * CHAR_BIT; i++) {
+ const char *val;
+
+ if (!(capsEnum->values & (1 << i)))
+ continue;
+
+ if ((val = (valToStr)(i)))
+ virBufferAsprintf(buf, "<value>%s</value>\n", val);
+ }
+ virBufferAdjustIndent(buf, -2);
+ virBufferAddLit(buf, "</enum>\n");
+
+ ret = 0;
+ cleanup:
+ return ret;
+}
+
+#define FORMAT_PROLOGUE(item) \
+ do { \
+ virBufferAsprintf(buf, "<" #item "
supported='%s'%s\n", \
+ item->device.supported ? "yes" : "no",
\
+ item->device.supported ? ">" :
"/>"); \
+ if (!item->device.supported) \
+ return; \
+ virBufferAdjustIndent(buf, 2); \
+ } while (0)
+
+#define FORMAT_EPILOGUE(item) \
+ do { \
+ virBufferAdjustIndent(buf, -2); \
+ virBufferAddLit(buf, "</" #item ">\n");
\
+ } while (0)
+
+#define ENUM_PROCESS(master, capsEnum, valToStr) \
+ do { \
+ virDomainCapsEnumFormat(buf, &master->capsEnum, \
+ #capsEnum, valToStr); \
+ } while (0)
+
+static void
+virDomainCapsDeviceDiskFormat(virBufferPtr buf,
+ virDomainCapsDeviceDiskPtr const disk)
+{
+ FORMAT_PROLOGUE(disk);
+
+ ENUM_PROCESS(disk, diskDevice, virDomainDiskDeviceTypeToString);
+ ENUM_PROCESS(disk, bus, virDomainDiskBusTypeToString);
+
+ FORMAT_EPILOGUE(disk);
+}
+
+
+static void
+virDomainCapsDeviceHostdevFormat(virBufferPtr buf,
+ virDomainCapsDeviceHostdevPtr const hostdev)
+{
+ FORMAT_PROLOGUE(hostdev);
+
+ ENUM_PROCESS(hostdev, mode, virDomainHostdevModeTypeToString);
+ ENUM_PROCESS(hostdev, startupPolicy, virDomainStartupPolicyTypeToString);
+ ENUM_PROCESS(hostdev, subsysType, virDomainHostdevSubsysTypeToString);
+ ENUM_PROCESS(hostdev, capsType, virDomainHostdevCapsTypeToString);
+ ENUM_PROCESS(hostdev, pciBackend, virDomainHostdevSubsysPCIBackendTypeToString);
+
+ FORMAT_EPILOGUE(hostdev);
+}
+
+
+static int
+virDomainCapsFormatInternal(virBufferPtr buf,
+ virDomainCapsPtr const caps)
+{
+ const char *virttype_str = virDomainVirtTypeToString(caps->virttype);
+ const char *arch_str = virArchToString(caps->arch);
+
+ virBufferAddLit(buf, "<domainCapabilities>\n");
+ virBufferAdjustIndent(buf, 2);
+
+ virBufferAsprintf(buf, "<path>%s</path>\n", caps->path);
+ virBufferAsprintf(buf, "<domain>%s</domain>\n", virttype_str);
+ virBufferAsprintf(buf, "<machine>%s</machine>\n",
caps->machine);
+ virBufferAsprintf(buf, "<arch>%s</arch>\n", arch_str);
+
+ if (caps->maxvcpus)
+ virBufferAsprintf(buf, "<vcpu max='%d'/>\n",
caps->maxvcpus);
+
+ virBufferAddLit(buf, "<devices>\n");
+ virBufferAdjustIndent(buf, 2);
+
+ virDomainCapsDeviceDiskFormat(buf, &caps->disk);
+ virDomainCapsDeviceHostdevFormat(buf, &caps->hostdev);
+
+ virBufferAdjustIndent(buf, -2);
+ virBufferAddLit(buf, "</devices>\n");
+
+ virBufferAdjustIndent(buf, -2);
+ virBufferAddLit(buf, "</domainCapabilities>\n");
+ return 0;
+}
+
+
+char *
+virDomainCapsFormat(virDomainCapsPtr const caps)
+{
+ virBuffer buf = VIR_BUFFER_INITIALIZER;
+
+ if (virDomainCapsFormatInternal(&buf, caps) < 0) {
+ virBufferFreeAndReset(&buf);
+ return NULL;
+ }
+
+ return virBufferContentAndReset(&buf);
+}
diff --git a/src/conf/domain_capabilities.h b/src/conf/domain_capabilities.h
new file mode 100644
index 0000000..731e66f
--- /dev/null
+++ b/src/conf/domain_capabilities.h
@@ -0,0 +1,103 @@
+/*
+ * domain_capabilities.h: domain capabilities XML processing
+ *
+ * Copyright (C) 2014 Red Hat, Inc.
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library. If not, see
+ * <http://www.gnu.org/licenses/>;.
+ *
+ * Author: Michal Privoznik <mprivozn(a)redhat.com>
+ */
+
+#ifndef __DOMAIN_CAPABILITIES_H__
+# define __DOMAIN_CAPABILITIES_H__
+
+# include "internal.h"
+# include "domain_conf.h"
+
+typedef const char * (*virDomainCapsValToStr)(int value);
+
+typedef struct _virDomainCaps virDomainCaps;
+typedef virDomainCaps *virDomainCapsPtr;
+
+typedef struct _virDomainCapsEnum virDomainCapsEnum;
+typedef virDomainCapsEnum *virDomainCapsEnumPtr;
+struct _virDomainCapsEnum {
+ unsigned int values; /* Bitmask of values supported in the corresponding enum */
+};
+
+typedef struct _virDomainCapsDevice virDomainCapsDevice;
+typedef virDomainCapsDevice *virDomainCapsDevicePtr;
+struct _virDomainCapsDevice {
+ bool supported; /* true if <devtype> is supported by hypervisor */
+};
+
+typedef struct _virDomainCapsDeviceDisk virDomainCapsDeviceDisk;
+typedef virDomainCapsDeviceDisk *virDomainCapsDeviceDiskPtr;
+struct _virDomainCapsDeviceDisk {
+ virDomainCapsDevice device;
+ virDomainCapsEnum diskDevice; /* Info about virDomainDiskDevice enum values */
+ virDomainCapsEnum bus; /* Info about virDomainDiskBus enum values */
+ /* add new fields here */
+};
+
+typedef struct _virDomainCapsDeviceHostdev virDomainCapsDeviceHostdev;
+typedef virDomainCapsDeviceHostdev *virDomainCapsDeviceHostdevPtr;
+struct _virDomainCapsDeviceHostdev {
+ virDomainCapsDevice device;
+ virDomainCapsEnum mode; /* Info about virDomainHostdevMode */
+ virDomainCapsEnum startupPolicy; /* Info about virDomainStartupPolicy */
+ virDomainCapsEnum subsysType; /* Info about virDomainHostdevSubsysType */
+ virDomainCapsEnum capsType; /* Info about virDomainHostdevCapsType */
+ virDomainCapsEnum pciBackend; /* Info about
virDomainHostdevSubsysPCIBackendType */
+ /* add new fields here */
+};
+
+struct _virDomainCaps {
+ virObjectLockable parent;
+
+ char *path; /* path to emulator binary */
+ virDomainVirtType virttype; /* virtualization type */
+ char *machine; /* machine type */
+ virArch arch; /* domain architecture */
+
+ /* Some machine specific info */
+ int maxvcpus;
+
+ virDomainCapsDeviceDisk disk;
+ virDomainCapsDeviceHostdev hostdev;
+ /* add new domain devices here */
+};
+
+virDomainCapsPtr virDomainCapsNew(const char *path,
+ const char *machine,
+ virArch arch,
+ virDomainVirtType virttype);
+
+# define VIR_DOMAIN_CAPS_ENUM_SET(capsEnum, ...) \
+ do { \
+ unsigned int __values[] = {__VA_ARGS__}; \
+ size_t __nvalues = ARRAY_CARDINALITY(__values); \
+ virDomainCapsEnumSet(&(capsEnum), #capsEnum, \
+ __nvalues, __values); \
+ } while (0)
+
+int virDomainCapsEnumSet(virDomainCapsEnumPtr capsEnum,
+ const char *capsEnumName,
+ size_t nvalues,
+ unsigned int *values);
+void virDomainCapsEnumClear(virDomainCapsEnumPtr capsEnum);
+
+char * virDomainCapsFormat(virDomainCapsPtr const caps);
+#endif /* __DOMAIN_CAPABILITIES_H__ */
diff --git a/src/libvirt_private.syms b/src/libvirt_private.syms
index 1e1dd84..40585bd 100644
--- a/src/libvirt_private.syms
+++ b/src/libvirt_private.syms
@@ -130,6 +130,13 @@ virDomainAuditStop;
virDomainAuditVcpu;
+# conf/domain_capabilities.h
+virDomainCapsEnumClear;
+virDomainCapsEnumSet;
+virDomainCapsFormat;
+virDomainCapsNew;
+
+
# conf/domain_conf.h
virBlkioDeviceArrayClear;
virDiskNameToBusDeviceIndex;
diff --git a/tests/Makefile.am b/tests/Makefile.am
index 025b847..97af0d9 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -74,6 +74,8 @@ EXTRA_DIST = \
commanddata \
confdata \
cputestdata \
+ domaincapsschemadata \
+ domaincapsschematest \
domainconfdata \
domainschemadata \
domainschematest \
@@ -167,6 +169,7 @@ test_programs = virshtest sockettest \
virnetdevbandwidthtest \
virkmodtest \
vircapstest \
+ domaincapstest \
domainconftest \
virhostdevtest \
vircaps2xmltest \
@@ -318,6 +321,7 @@ test_scripts = \
networkschematest \
storagepoolschematest \
storagevolschematest \
+ domaincapsschematest \
domainschematest \
nodedevschematest \
nwfilterschematest \
@@ -827,6 +831,10 @@ vircaps2xmltest_SOURCES = \
vircaps2xmltest.c testutils.h testutils.c
vircaps2xmltest_LDADD = $(LDADDS)
+domaincapstest_SOURCES = \
+ domaincapstest.c testutils.h testutils.c
+domaincapstest_LDADD = $(LDADDS)
+
if WITH_LIBVIRTD
libvirtdconftest_SOURCES = \
libvirtdconftest.c testutils.h testutils.c \
diff --git a/tests/domaincapsschemadata/domaincaps-basic.xml
b/tests/domaincapsschemadata/domaincaps-basic.xml
new file mode 100644
index 0000000..9963519
--- /dev/null
+++ b/tests/domaincapsschemadata/domaincaps-basic.xml
@@ -0,0 +1,10 @@
+<domainCapabilities>
+ <path>/bin/emulatorbin</path>
+ <domain>uml</domain>
+ <machine>my-machine-type</machine>
+ <arch>x86_64</arch>
+ <devices>
+ <disk supported='no'/>
+ <hostdev supported='no'/>
+ </devices>
+</domainCapabilities>
diff --git a/tests/domaincapsschemadata/domaincaps-full.xml
b/tests/domaincapsschemadata/domaincaps-full.xml
new file mode 100644
index 0000000..58dd4cb
--- /dev/null
+++ b/tests/domaincapsschemadata/domaincaps-full.xml
@@ -0,0 +1,56 @@
+<domainCapabilities>
+ <path>/bin/emulatorbin</path>
+ <domain>kvm</domain>
+ <machine>my-machine-type</machine>
+ <arch>x86_64</arch>
+ <vcpu max='255'/>
+ <devices>
+ <disk supported='yes'>
+ <enum name='diskDevice'>
+ <value>disk</value>
+ <value>cdrom</value>
+ <value>floppy</value>
+ <value>lun</value>
+ </enum>
+ <enum name='bus'>
+ <value>ide</value>
+ <value>fdc</value>
+ <value>scsi</value>
+ <value>virtio</value>
+ <value>xen</value>
+ <value>usb</value>
+ <value>uml</value>
+ <value>sata</value>
+ <value>sd</value>
+ </enum>
+ </disk>
+ <hostdev supported='yes'>
+ <enum name='mode'>
+ <value>subsystem</value>
+ <value>capabilities</value>
+ </enum>
+ <enum name='startupPolicy'>
+ <value>default</value>
+ <value>mandatory</value>
+ <value>requisite</value>
+ <value>optional</value>
+ </enum>
+ <enum name='subsysType'>
+ <value>usb</value>
+ <value>pci</value>
+ <value>scsi</value>
+ </enum>
+ <enum name='capsType'>
+ <value>storage</value>
+ <value>misc</value>
+ <value>net</value>
+ </enum>
+ <enum name='pciBackend'>
+ <value>default</value>
+ <value>kvm</value>
+ <value>vfio</value>
+ <value>xen</value>
+ </enum>
+ </hostdev>
+ </devices>
+</domainCapabilities>
diff --git a/tests/domaincapsschematest b/tests/domaincapsschematest
new file mode 100755
index 0000000..9baf44a
--- /dev/null
+++ b/tests/domaincapsschematest
@@ -0,0 +1,11 @@
+#!/bin/sh
+
+: ${srcdir=.}
+. $srcdir/test-lib.sh
+. $abs_srcdir/schematestutils.sh
+
+DIRS=""
+DIRS="$DIRS domaincapsschemadata"
+SCHEMA="domaincaps.rng"
+
+check_schema "$DIRS" "$SCHEMA"
diff --git a/tests/domaincapstest.c b/tests/domaincapstest.c
new file mode 100644
index 0000000..6cdd086
--- /dev/null
+++ b/tests/domaincapstest.c
@@ -0,0 +1,149 @@
+/*
+ * Copyright (C) Red Hat, Inc. 2014
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library. If not, see
+ * <http://www.gnu.org/licenses/>;.
+ *
+ * Authors:
+ * Michal Privoznik <mprivozn(a)redhat.com>
+ */
+
+#include <config.h>
+#include <stdlib.h>
+
+#include "testutils.h"
+#include "domain_capabilities.h"
+
+
+#define VIR_FROM_THIS VIR_FROM_NONE
+
+typedef void (*virDomainCapsFill)(virDomainCapsPtr domCaps,
+ void *opaque);
+
+#define SET_ALL_BITS(x) \
+ memset(&(x.values), 0xff, sizeof(x.values))
+
+static void
+fillAll(virDomainCapsPtr domCaps,
+ void *opaque ATTRIBUTE_UNUSED)
+{
+ virDomainCapsDeviceDiskPtr disk = &domCaps->disk;
+ virDomainCapsDeviceHostdevPtr hostdev = &domCaps->hostdev;
+ domCaps->maxvcpus = 255;
+
+ disk->device.supported = true;
+ SET_ALL_BITS(disk->diskDevice);
+ SET_ALL_BITS(disk->bus);
+
+ hostdev->device.supported = true;
+ SET_ALL_BITS(hostdev->mode);
+ SET_ALL_BITS(hostdev->startupPolicy);
+ SET_ALL_BITS(hostdev->subsysType);
+ SET_ALL_BITS(hostdev->capsType);
+ SET_ALL_BITS(hostdev->pciBackend);
+}
+
+static virDomainCapsPtr
+buildVirDomainCaps(const char *emulatorbin,
+ const char *machine,
+ virArch arch,
+ virDomainVirtType type,
+ virDomainCapsFill fillFunc,
+ void *opaque)
+{
+ virDomainCapsPtr domCaps;
+
+ if (!(domCaps = virDomainCapsNew(emulatorbin, machine, arch, type)))
+ goto cleanup;
+
+ if (fillFunc)
+ fillFunc(domCaps, opaque);
+
+ cleanup:
+ return domCaps;
+}
+
+struct test_virDomainCapsFormatData {
+ const char *filename;
+ const char *emulatorbin;
+ const char *machine;
+ virArch arch;
+ virDomainVirtType type;
+ virDomainCapsFill fillFunc;
+ void *opaque;
+};
+
+static int
+test_virDomainCapsFormat(const void *opaque)
+{
+ struct test_virDomainCapsFormatData *data =
+ (struct test_virDomainCapsFormatData *) opaque;
+ virDomainCapsPtr domCaps = NULL;
+ char *path = NULL;
+ char *domCapsXML = NULL;
+ char *domCapsFromFile = NULL;
+ int ret = -1;
+
+ if (virAsprintf(&path, "%s/domaincapsschemadata/domaincaps-%s.xml",
+ abs_srcdir, data->filename) < 0)
+ goto cleanup;
+
+ if (virFileReadAll(path, 8192, &domCapsFromFile) < 0)
+ goto cleanup;
+
+ if (!(domCaps = buildVirDomainCaps(data->emulatorbin, data->machine,
+ data->arch, data->type,
+ data->fillFunc, data->opaque)))
+ goto cleanup;
+
+ if (!(domCapsXML = virDomainCapsFormat(domCaps)))
+ goto cleanup;
+
+ if (STRNEQ(domCapsFromFile, domCapsXML)) {
+ virtTestDifference(stderr, domCapsFromFile, domCapsXML);
+ goto cleanup;
+ }
+
+ ret = 0;
+ cleanup:
+ VIR_FREE(domCapsFromFile);
+ VIR_FREE(domCapsXML);
+ VIR_FREE(path);
+ virObjectUnref(domCaps);
+ return ret;
+}
+
+static int
+mymain(void)
+{
+ int ret = 0;
+
+#define DO_TEST(Filename, Emulatorbin, Machine, Arch, Type, ...) \
+ do { \
+ struct test_virDomainCapsFormatData data = {.filename = Filename, \
+ .emulatorbin = Emulatorbin, .machine = Machine, .arch = Arch, \
+ .type = Type, __VA_ARGS__}; \
+ if (virtTestRun(Filename, test_virDomainCapsFormat, &data) < 0)
\
+ ret = -1; \
+ } while (0)
+
+ DO_TEST("basic", "/bin/emulatorbin",
"my-machine-type",
+ VIR_ARCH_X86_64, VIR_DOMAIN_VIRT_UML);
+ DO_TEST("full", "/bin/emulatorbin", "my-machine-type",
+ VIR_ARCH_X86_64, VIR_DOMAIN_VIRT_KVM, .fillFunc = fillAll);
+
+ return ret;
+}
+
+VIRT_TEST_MAIN(mymain)
--
1.8.5.5
9:28 a.m.
New subject: [libvirt] [PATCH for 1.2.7 1/8] Introduce domain_capabilities
On Mon, Jun 30, 2014 at 05:31:44PM +0200, Michal Privoznik wrote:
This new module holds and formats capabilities for emulator. If you
are about to create a new domain, you may want to know what is the
host or hypervisor capable of. To make sure we don't regress on the
XML, the formatting is not something left for each driver to
implement, rather there's general format function.
The domain capabilities is a lockable object (even though the locking
is not necessary yet) which uses reference counter.
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
---
docs/formatdomaincaps.html.in | 200 +++++++++++++++++++
docs/schemas/Makefile.am | 1 +
docs/schemas/domaincaps.rng | 90 +++++++++
docs/sitemap.html.in | 4 +
libvirt.spec.in | 1 +
mingw-libvirt.spec.in | 2 +
po/POTFILES.in | 1 +
src/Makefile.am | 1 +
src/conf/domain_capabilities.c | 254 ++++++++++++++++++++++++
src/conf/domain_capabilities.h | 103 ++++++++++
src/libvirt_private.syms | 7 +
tests/Makefile.am | 8 +
tests/domaincapsschemadata/domaincaps-basic.xml | 10 +
tests/domaincapsschemadata/domaincaps-full.xml | 56 ++++++
tests/domaincapsschematest | 11 +
tests/domaincapstest.c | 149 ++++++++++++++
16 files changed, 898 insertions(+)
create mode 100644 docs/formatdomaincaps.html.in
create mode 100644 docs/schemas/domaincaps.rng
create mode 100644 src/conf/domain_capabilities.c
create mode 100644 src/conf/domain_capabilities.h
create mode 100644 tests/domaincapsschemadata/domaincaps-basic.xml
create mode 100644 tests/domaincapsschemadata/domaincaps-full.xml
create mode 100755 tests/domaincapsschematest
create mode 100644 tests/domaincapstest.c
ACK
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 :|
9:32 a.m.
New subject: [libvirt] [PATCH for 1.2.7 1/8] Introduce domain_capabilities
On 06/30/2014 11:31 AM, Michal Privoznik wrote:
This new module holds and formats capabilities for emulator. If you
are about to create a new domain, you may want to know what is the
host or hypervisor capable of. To make sure we don't regress on the
XML, the formatting is not something left for each driver to
implement, rather there's general format function.
The domain capabilities is a lockable object (even though the locking
is not necessary yet) which uses reference counter.
I started looking at these yesterday, but ended up having more questions
than I originally thought I would, so perhaps better to get some
answered. Of course it's already too wordy (sorry)...
I was trying to envision use cases - that is how is this expected to be
used and what "knowledge" is assumed of the caller/user vs. being
designed to a more naive user trying to glean information about what's
available. You have a very specific use case described - can I determine
if vfio is supported, but that requires someone knowing quite a bit of
information that isn't easily accessible unless you read sources or have
a bit of history built up.
For the domcapabilities command that eventually gets added - how does
one know what to provide for the 4 options without knowing a bit about
the environment. It seems the assumption is the user knows to pass
certain elements.
The 'virttype' is pretty easy - that comes from the connection - so I
wonder why it's a parameter to be provided. Does one really have to have
a connection to get the data?
The 'emulatorbin' is less obvious. If it's not passed, there is a way to
get the default value given that you have a virttype, an os type, and an
os arch using virCapabilitiesDefaultGuestEmulator(). What if someone
provides "/usr/bin/qemu-kvm" or "/usr/libexec/qemu-kvm" or is there
an
expectation of /usr/bin/qemu-system-x86_64?
The 'arch' requires a bit more knowledge, but is certainly "obtainable"
as a default by the current host arch, right? There's also
virCapabilitiesDefaultGuestArch(). However, if someone was looking to
find out what was running on the remote connection (not the local
machine), then that assumption would be incorrect. Seems we should be
able to figure out what arch is associated with the connection.
I think 'machine' is perhaps the most odd to provide; however, like arch
and emulatorbin, there is virCapabilitiesDefaultGuestMachine() to help
you out. For this if one passed "pc" does that work - or do they have
to pass something like "pc-i440fx-1.6" with the next question being how
would they know to generate that?
Reading the domain_conf code - only 'virttype' and 'os_type' really seem
to be required - everything else can be figured out "by default" given
the two. Having (a) virsh command(s) to display possible options may be
a nice addition, especially for the naive user... Should be very easy to
add something that could print out the virArch options. Leaving only the
need to know what the os_type is before behing able to at least fetch
defaults and generate XML output. Perhaps someone just using "virsh
domcapabilities" would print out tables of all arch's.. Similarly if
arch was provided, then print out all emulatorbin's (if that's possible)
for the arch or just the default emulatorbin... Given an arch and
emulatorbin, then print out the machines available.
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
---
docs/formatdomaincaps.html.in | 200 +++++++++++++++++++
docs/schemas/Makefile.am | 1 +
docs/schemas/domaincaps.rng | 90 +++++++++
docs/sitemap.html.in | 4 +
libvirt.spec.in | 1 +
mingw-libvirt.spec.in | 2 +
po/POTFILES.in | 1 +
src/Makefile.am | 1 +
src/conf/domain_capabilities.c | 254 ++++++++++++++++++++++++
src/conf/domain_capabilities.h | 103 ++++++++++
src/libvirt_private.syms | 7 +
tests/Makefile.am | 8 +
tests/domaincapsschemadata/domaincaps-basic.xml | 10 +
tests/domaincapsschemadata/domaincaps-full.xml | 56 ++++++
tests/domaincapsschematest | 11 +
tests/domaincapstest.c | 149 ++++++++++++++
16 files changed, 898 insertions(+)
create mode 100644 docs/formatdomaincaps.html.in
create mode 100644 docs/schemas/domaincaps.rng
create mode 100644 src/conf/domain_capabilities.c
create mode 100644 src/conf/domain_capabilities.h
create mode 100644 tests/domaincapsschemadata/domaincaps-basic.xml
create mode 100644 tests/domaincapsschemadata/domaincaps-full.xml
create mode 100755 tests/domaincapsschematest
create mode 100644 tests/domaincapstest.c
diff --git a/docs/formatdomaincaps.html.in b/docs/formatdomaincaps.html.in
new file mode 100644
index 0000000..cfd61d9
--- /dev/null
+++ b/docs/formatdomaincaps.html.in
Since there's a "Capabilities" page describing the Driver (Host/Guest)
Capabilities and now this one for Domain - do you see a future need for
storage, network, etc. type capabilities? If so, other than the "volume
of data" then why not extend capabilities so that it could list
everything available for everything we know about? e.g.:
<capabilities>
<host... />
<guest... />
<domain... />
<storage... />
<network... />
<interface... />
</capabilities>
Architecturally, does it make sense to merge them or keep then separate?
There seems to be a relationship between them. Furthermore, if the goal
is to just provide information, then using one pile of xml output to
store everything may be useful to someone. For the more seasoned
individual using a specific/directed API that is planned will provide
the directed answer. I think the 'virsh capabilies' output certainly
shows it's possible to grab/use the various arch, machine, emulator, and
domain type values to generate lengthy output listing every possible option.
[1]If this page is kept, then perhaps modify the sitemap heading to be
"Host/Guest" or "Driver" Capabilities...
I also think perhaps that this .in file could wait until at least patch
2 where virConnectGetDomainCapabilities() is exposed... So a pointer to
it can be added. BTW: Look at api.html.in - there are examples on how to
directly link the API to the API description, eg.
"<code
class="docref">virConnectGetDomainCapabilities</code>"
@@ -0,0 +1,200 @@
+<?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>Domain capabilities XML format</h1>
+
+ <ul id="toc"></ul>
+
+ <h2><a name="Motivation">Motivation</a></h2>
s/Motivation/Overview/
+
+ <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>
"older one" ??? Contextually what is the older one? Naive or newer
user can be confused...
+
+ <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>
[assuming this page sticks... Consider...]
While the <a href="formatcaps.html">Driver Capabilities</a> provides
the
host capabilities (e.g NUMA topology, security models in effect, etc.),
the Domain Capabilities provides the hypervisor specific capabilities
for Management Applications to query and make decisions regarding what
to utilize.
The Domain Capabilities [can|will] provide information such as the
correct combination of devices and drivers that are supported. Knowing
which host and hypervisor specific options are available or supported
would allow the management application to choose an appropriate mode for
a pass-through host device as well as which adapter to utilize.
[does this make sense] For example, choosing a specific host device for
pass-through device using "vfio" requires a specific QEMU version to be
installed; whereas, using ["????"] is the older legacy model employed by
KVM.
+
+ <h2><a name="elements">Element and attribute
overview</a></h2>
+
[Also like the formatcaps.html.in page - a <pre> </pre> with just the
API listed would be nice - although I wouldn't put the args there - just
the pointer, such as:]
<p> A new query interface was added to the virConnect API's to retrieve
the XML listing of the set of domain capabilities:
<pre>
<code class="docref">virConnectGetDomainCapabilities</code>
</pre>
<span class="since">Since 1.2.7</span>.</p>
[I also think formatcaps.html.in should use the same <code
class="docref">...</code> syntax, but that's a different issue]
[Perhaps some virsh command options that can be provided to display the
information. Similarly adding a <pre> </pre> on the capabilities page to
show how to get the information using virsh capabilities, but again
that's a different issue. ]
+ <p>The root element that emulator capability XML document
starts with has
+ name <code>domainCapabilities</code>. It contains at least four direct
+ child elements:</p>
+
+<pre>
+<domainCapabilities>
+ <path>/usr/bin/qemu-system-x86_64</path>
+ <domain>kvm</domain>
+ <machine>pc-i440fx-2.1</machine>
+ <arch>x86_64</arch>
+ ...
+</domainCapabilities>
+</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>
Personally <domain> seems redundant. Perhaps follow code and use
<virttype>...
+
+ <dt>machine</dt>
+ <dd>The domain's <a
href="formatdomain.html#elementsOSBIOS">machine
+ type</a>.</dd>
Somewhat of a nit, but the link provides only vague information about
<machine> and points off to the formatcaps.html.in page which provides
just "pc" and "isapc" as "<machine>" examples. Going
back to a comment I
made earlier about how does one know what to provide...
+
+ <dt>arch</dt>
+ <dd>The domain's <a
href="formatdomain.html#elementsOSBIOS">
+ architecture</a>.</dd>
+
Similar, but at least there is an "<arch name="..."/> found. The
point
being <machine> and <arch> are discussed in the <type> explanation -
it's not well described.
+ </dl>
+
+ <h3><a name="elementsCPUAllocation">CPU
Allocation</a></h3>
+
There's no textual context/introduction here.
+<pre>
+<domainCapabilities>
+ ...
+ <vcpu max='255'/>
+ ...
+</domainCapabilities>
+</pre>
+
+ <dl>
+ <dt>vcpu</dt>
+ <dd>The maximum number of supported virtual CPUs</dd>
+ </dl>
+
+ <h3><a name="elementsDevices">Devices</a></h3>
+
+ <p>
+ The final set of XML elements are all used to describe supported devices
+ and their capabilities. All devices occur as children of the main
+ <code>devices</code> element.
+ </p>
+
s/are all used to describe/describe the/
+<pre>
+<domainCapabilities>
+ ...
+ <devices>
+ <disk supported='yes'>
+ <enum name='diskDevice'>
+ <value>disk</value>
+ <value>cdrom</value>
+ <value>floppy</value>
+ <value>lun</value>
+ </enum>
+ ...
+ </disk>
+ <hostdev supported='no'/>
+ </devices>
+</domainCapabilities>
+</pre>
+
+ <p>All reported capabilities share the way that they are expressed. In the
+ example above we can see what disk devices are supported
(<code>disk</code>,
+ <code>cdrom</code>, <code>floppy</code> and
<code>lun</code>).</p>
[Consider]
Reported capabilities are expressed as an enumerated list of available
options for each of the element or attribute. For example, the "<disk>"
element has an attribute "device=" which can support the values
<code>disk</code>, <code>cdrom</code>,
<code>floppy</code>, or
<code>lun</code>.
+
+ <h4><a name="elementsDisks">Hard drives, floppy disks,
CDROMs</a></h4>
+ <p>Disk capabilities are exposed under <code>disk</code> element.
For
+ instance:</p>
+
+<pre>
+<domainCapabilities>
+ ...
+ <devices>
+ <disk supported='yes'>
+ <enum name='diskDevice'>
+ <value>disk</value>
+ <value>cdrom</value>
+ <value>floppy</value>
+ <value>lun</value>
+ </enum>
+ <enum name='bus'>
+ <value>ide</value>
+ <value>fdc</value>
+ <value>scsi</value>
+ <value>virtio</value>
+ <value>xen</value>
+ <value>usb</value>
+ <value>uml</value>
+ <value>sata</value>
+ <value>sd</value>
+ </enum>
+ </disk>
+ ...
+ </devices>
+</domainCapabilities>
+</pre>
+
+ <dl>
+ <dt>diskDevice</dt>
+ <dd>What disk types are supported.</dd>
[consider]
Options for the "device" attribute of the "<disk>" element.
+
+ <dt>bus</dt>
+ <dd>The bus within a domain that disk may occur on</dd>
[consider]
Options for the "bus" attribute of the "<target>" element for a
"<disk>".
+ </dl>
+
+ <h4><a name="elementsHostDev">Host device
assignment</a></h4>
+ <p>Some host devices can be passed through to a guest (e.g. USB, PCI and
+ SCSI). Well, only if the following is enabled:</p>
+
s/. Well, only if the following is enabled/ as long as the
<code>supported</code> attribute is set to "yes"./
+<pre>
+<domainCapabilities>
+ ...
+ <devices>
+ <hostdev supported='yes'>
+ <enum name='mode'>
+ <value>subsystem</value>
+ <value>capabilities</value>
+ </enum>
+ <enum name='startupPolicy'>
+ <value>default</value>
+ <value>mandatory</value>
+ <value>requisite</value>
+ <value>optional</value>
+ </enum>
+ <enum name='subsysType'>
+ <value>usb</value>
+ <value>pci</value>
+ <value>scsi</value>
+ </enum>
+ <enum name='capsType'>
+ <value>storage</value>
+ <value>misc</value>
+ <value>net</value>
+ </enum>
+ <enum name='pciBackend'>
+ <value>default</value>
+ <value>kvm</value>
+ <value>vfio</value>
+ <value>xen</value>
+ </enum>
+ </hostdev>
+ </devices>
+</domainCapabilities>
+</pre>
+
+ <dl>
+ <dt>mode</dt>
+ <dd>Describes what passthrough modes are supported</dd>
+
[consider]
Options for the "mode" attribute of the "<hostdev>" element.
[similarly for the rest]
+ <dt>startupPolicy</dt>
+ <dd>What startup policy modes are known to libvirt</dd>
+
+ <dt>subsysType</dt>
+ <dd>Enumerates subsystems that are capable of passing through a
device</dd>
+
+ <dt>capsType</dt>
+ <dd>host device mode</dd>
+
+ <dt>pciBackend</dt>
+ <dd>Which backend should be used to manage device passthrough</dd>
+ </dl>
+ </body>
+</html>
diff --git a/docs/schemas/Makefile.am b/docs/schemas/Makefile.am
index d71c327..0e14dc6 100644
--- a/docs/schemas/Makefile.am
+++ b/docs/schemas/Makefile.am
@@ -19,6 +19,7 @@ schema_DATA = \
basictypes.rng \
capability.rng \
domain.rng \
+ domaincaps.rng \
domaincommon.rng \
domainsnapshot.rng \
interface.rng \
diff --git a/docs/schemas/domaincaps.rng b/docs/schemas/domaincaps.rng
new file mode 100644
index 0000000..627b699
--- /dev/null
+++ b/docs/schemas/domaincaps.rng
@@ -0,0 +1,90 @@
+<?xml version="1.0"?>
+<!-- A Relax NG schema for the libvirt domain capabilities XML format -->
+<grammar xmlns="http://relaxng.org/ns/structure/1.0"
datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes">
+ <include href='basictypes.rng'/>
+ <start>
+ <ref name='domainCapabilities'/>
+ </start>
+
+
+ <define name='domainCapabilities'>
+ <element name='domainCapabilities'>
+ <interleave>
+ <element name='path'>
+ <ref name="absFilePath"/>
+ </element>
+ <element name='domain'>
Like noted before should change - perhaps model code "virttype"
+ <text/>
+ </element>
+ <element name='machine'>
+ <text/>
+ </element>
+ <element name='arch'>
+ <text/>
+ </element>
+ <optional>
+ <ref name='vcpu'/>
+ </optional>
+ <optional>
+ <ref name='devices'/>
+ </optional>
+ </interleave>
+ </element>
+ </define>
+
+ <define name='vcpu'>
+ <element name='vcpu'>
+ <attribute name='max'>
+ <ref name='unsignedInt'/>
+ </attribute>
+ <empty/>
+ </element>
+ </define>
+
+ <define name='devices'>
+ <element name='devices'>
+ <interleave>
+ <ref name='disk'/>
+ <ref name='hostdev'/>
+ </interleave>
+ </element>
+ </define>
+
+ <define name='disk'>
+ <element name='disk'>
+ <ref name='supported'/>
+ <ref name='enum'/>
+ </element>
+ </define>
+
+ <define name='hostdev'>
+ <element name='hostdev'>
+ <ref name='supported'/>
+ <ref name='enum'/>
+ </element>
+ </define>
+
+ <define name='supported'>
+ <attribute name='supported'>
+ <choice>
+ <value>yes</value>
+ <value>no</value>
+ </choice>
+ </attribute>
+ </define>
+
+ <define name='enum'>
+ <zeroOrMore>
+ <element name='enum'>
+ <attribute name='name'>
+ <text/>
+ </attribute>
+ <zeroOrMore>
+ <element name='value'>
+ <text/>
+ </element>
+ </zeroOrMore>
+ </element>
+ </zeroOrMore>
+ </define>
+</grammar>
diff --git a/docs/sitemap.html.in b/docs/sitemap.html.in
index 78e84e3..1e91869 100644
--- a/docs/sitemap.html.in
+++ b/docs/sitemap.html.in
[1] Possible change to formatcaps.html to be "Driver capabilities"
instead of just "Capabilities"
@@ -175,6 +175,10 @@
<span>The driver capabilities XML format</span>
[1] Possible text change to use "Host/Guest" Capabilities?
</li>
<li>
+ <a href="formatdomaincaps.html">Domain
capabilities</a>
+ <span>The domain capabilities XML format</span>
+ </li>
+ <li>
<a href="formatnode.html">Node Devices</a>
<span>The host device XML format</span>
</li>
diff --git a/libvirt.spec.in b/libvirt.spec.in
index 2ec7eed..f0bf737 100644
--- a/libvirt.spec.in
+++ b/libvirt.spec.in
@@ -2164,6 +2164,7 @@ exit 0
%{_datadir}/libvirt/schemas/basictypes.rng
%{_datadir}/libvirt/schemas/capability.rng
%{_datadir}/libvirt/schemas/domain.rng
+%{_datadir}/libvirt/schemas/domaincaps.rng
%{_datadir}/libvirt/schemas/domaincommon.rng
%{_datadir}/libvirt/schemas/domainsnapshot.rng
%{_datadir}/libvirt/schemas/interface.rng
It seems something is always missed in the spec file - is this all
that's necessary? I think the po and html files are included en masse,
but I guess better safe than sorry...
The question being asked - did you build rpm or dist (mumblyfratz)?
diff --git a/mingw-libvirt.spec.in b/mingw-libvirt.spec.in
index 91c2dc2..a555f9c 100644
--- a/mingw-libvirt.spec.in
+++ b/mingw-libvirt.spec.in
@@ -205,6 +205,7 @@ rm -rf $RPM_BUILD_ROOT%{mingw64_libexecdir}/libvirt-guests.sh
%{mingw32_datadir}/libvirt/schemas/basictypes.rng
%{mingw32_datadir}/libvirt/schemas/capability.rng
%{mingw32_datadir}/libvirt/schemas/domain.rng
+%{mingw32_datadir}/libvirt/schemas/domaincaps.rng
%{mingw32_datadir}/libvirt/schemas/domaincommon.rng
%{mingw32_datadir}/libvirt/schemas/domainsnapshot.rng
%{mingw32_datadir}/libvirt/schemas/interface.rng
@@ -265,6 +266,7 @@ rm -rf $RPM_BUILD_ROOT%{mingw64_libexecdir}/libvirt-guests.sh
%{mingw64_datadir}/libvirt/schemas/basictypes.rng
%{mingw64_datadir}/libvirt/schemas/capability.rng
%{mingw64_datadir}/libvirt/schemas/domain.rng
+%{mingw64_datadir}/libvirt/schemas/domaincaps.rng
%{mingw64_datadir}/libvirt/schemas/domaincommon.rng
%{mingw64_datadir}/libvirt/schemas/domainsnapshot.rng
%{mingw64_datadir}/libvirt/schemas/interface.rng
^^^and of course the other most forgotten area...^^^
diff --git a/po/POTFILES.in b/po/POTFILES.in
index 31a8381..70fb6c2 100644
--- a/po/POTFILES.in
+++ b/po/POTFILES.in
@@ -16,6 +16,7 @@ src/conf/capabilities.c
src/conf/cpu_conf.c
src/conf/device_conf.c
src/conf/domain_addr.c
+src/conf/domain_capabilities.c
src/conf/domain_conf.c
src/conf/domain_event.c
src/conf/interface_conf.c
diff --git a/src/Makefile.am b/src/Makefile.am
index 2b9ac61..e81af0c 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -248,6 +248,7 @@ NETDEV_CONF_SOURCES = \
DOMAIN_CONF_SOURCES = \
conf/capabilities.c conf/capabilities.h \
conf/domain_addr.c conf/domain_addr.h \
+ conf/domain_capabilities.c conf/domain_capabilities.h \
conf/domain_conf.c conf/domain_conf.h \
conf/domain_audit.c conf/domain_audit.h \
conf/domain_nwfilter.c conf/domain_nwfilter.h \
diff --git a/src/conf/domain_capabilities.c b/src/conf/domain_capabilities.c
new file mode 100644
index 0000000..df190eb
--- /dev/null
+++ b/src/conf/domain_capabilities.c
@@ -0,0 +1,254 @@
+/*
+ * domain_capabilities.c: domain capabilities XML processing
+ *
+ * Copyright (C) 2014 Red Hat, Inc.
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library. If not, see
+ * <http://www.gnu.org/licenses/>;.
+ *
+ * Author: Michal Privoznik <mprivozn(a)redhat.com>
+ */
+
+#include <config.h>
+
+#include "domain_capabilities.h"
+#include "domain_conf.h"
+#include "viralloc.h"
+#include "virstring.h"
+
+#define VIR_FROM_THIS VIR_FROM_CAPABILITIES
+
+static virClassPtr virDomainCapsClass;
+
+static void virDomainCapsDispose(void *obj);
+
+static int virDomainCapsOnceInit(void)
+{
+ if (!(virDomainCapsClass = virClassNew(virClassForObjectLockable(),
+ "virDomainCapsClass",
+ sizeof(virDomainCaps),
+ virDomainCapsDispose)))
+ return -1;
+ return 0;
+}
+
+
+VIR_ONCE_GLOBAL_INIT(virDomainCaps)
+
+
+static void
+virDomainCapsDispose(void *obj)
+{
+ virDomainCapsPtr caps = obj;
+
+ VIR_FREE(caps->path);
+ VIR_FREE(caps->machine);
+}
+
+
+virDomainCapsPtr
+virDomainCapsNew(const char *path,
+ const char *machine,
+ virArch arch,
+ virDomainVirtType virttype)
+{
+ virDomainCapsPtr caps = NULL;
+
+ if (virDomainCapsInitialize() < 0)
+ return NULL;
+
+ if (!(caps = virObjectLockableNew(virDomainCapsClass)))
+ return NULL;
+
+ if (VIR_STRDUP(caps->path, path) < 0 ||
+ VIR_STRDUP(caps->machine, machine) < 0)
+ goto error;
+ caps->arch = arch;
+ caps->virttype = virttype;
+
+ return caps;
+ error:
+ virObjectUnref(caps);
+ return NULL;
+}
+
+
+int
+virDomainCapsEnumSet(virDomainCapsEnumPtr capsEnum,
+ const char *capsEnumName,
+ size_t nvalues,
+ unsigned int *values)
+{
+ int ret = -1;
+ size_t i;
+
+ for (i = 0; i < nvalues; i++) {
+ unsigned int val = 1 << values[i];
+
+ if (!val) {
+ /* Integer overflow */
+ virReportError(VIR_ERR_INTERNAL_ERROR,
+ _("integer overflow on %s. Please contact the "
+ "libvirt development team at
libvir-list(a)redhat.com"),
+ capsEnumName);
+ goto cleanup;
+ }
+
+ capsEnum->values |= val;
+ }
+
+ ret = 0;
+ cleanup:
+ return ret;
+}
+
+
+void
+virDomainCapsEnumClear(virDomainCapsEnumPtr capsEnum)
+{
+ capsEnum->values = 0;
+}
+
+
+static int
+virDomainCapsEnumFormat(virBufferPtr buf,
+ virDomainCapsEnumPtr capsEnum,
+ const char *capsEnumName,
+ virDomainCapsValToStr valToStr)
+{
+ int ret = -1;
+ size_t i;
+
+ virBufferAsprintf(buf, "<enum name='%s'", capsEnumName);
+ if (!capsEnum->values) {
+ virBufferAddLit(buf, "/>\n");
+ ret = 0;
+ goto cleanup;
+ }
+ virBufferAddLit(buf, ">\n");
+ virBufferAdjustIndent(buf, 2);
+
+ for (i = 0; i < sizeof(capsEnum->values) * CHAR_BIT; i++) {
+ const char *val;
+
+ if (!(capsEnum->values & (1 << i)))
+ continue;
+
+ if ((val = (valToStr)(i)))
+ virBufferAsprintf(buf, "<value>%s</value>\n", val);
+ }
+ virBufferAdjustIndent(buf, -2);
+ virBufferAddLit(buf, "</enum>\n");
+
+ ret = 0;
+ cleanup:
+ return ret;
+}
+
+#define FORMAT_PROLOGUE(item) \
+ do { \
+ virBufferAsprintf(buf, "<" #item "
supported='%s'%s\n", \
+ item->device.supported ? "yes" : "no",
\
+ item->device.supported ? ">" :
"/>"); \
+ if (!item->device.supported) \
+ return; \
+ virBufferAdjustIndent(buf, 2); \
+ } while (0)
+
+#define FORMAT_EPILOGUE(item) \
+ do { \
+ virBufferAdjustIndent(buf, -2); \
+ virBufferAddLit(buf, "</" #item ">\n");
\
+ } while (0)
+
+#define ENUM_PROCESS(master, capsEnum, valToStr) \
+ do { \
+ virDomainCapsEnumFormat(buf, &master->capsEnum, \
+ #capsEnum, valToStr); \
+ } while (0)
+
+static void
+virDomainCapsDeviceDiskFormat(virBufferPtr buf,
+ virDomainCapsDeviceDiskPtr const disk)
+{
+ FORMAT_PROLOGUE(disk);
+
+ ENUM_PROCESS(disk, diskDevice, virDomainDiskDeviceTypeToString);
+ ENUM_PROCESS(disk, bus, virDomainDiskBusTypeToString);
+
+ FORMAT_EPILOGUE(disk);
+}
+
+
+static void
+virDomainCapsDeviceHostdevFormat(virBufferPtr buf,
+ virDomainCapsDeviceHostdevPtr const hostdev)
+{
+ FORMAT_PROLOGUE(hostdev);
+
+ ENUM_PROCESS(hostdev, mode, virDomainHostdevModeTypeToString);
+ ENUM_PROCESS(hostdev, startupPolicy, virDomainStartupPolicyTypeToString);
+ ENUM_PROCESS(hostdev, subsysType, virDomainHostdevSubsysTypeToString);
+ ENUM_PROCESS(hostdev, capsType, virDomainHostdevCapsTypeToString);
+ ENUM_PROCESS(hostdev, pciBackend, virDomainHostdevSubsysPCIBackendTypeToString);
+
+ FORMAT_EPILOGUE(hostdev);
+}
+
+
+static int
+virDomainCapsFormatInternal(virBufferPtr buf,
+ virDomainCapsPtr const caps)
+{
+ const char *virttype_str = virDomainVirtTypeToString(caps->virttype);
+ const char *arch_str = virArchToString(caps->arch);
+
+ virBufferAddLit(buf, "<domainCapabilities>\n");
+ virBufferAdjustIndent(buf, 2);
+
+ virBufferAsprintf(buf, "<path>%s</path>\n", caps->path);
+ virBufferAsprintf(buf, "<domain>%s</domain>\n", virttype_str);
<virttype>?
+ virBufferAsprintf(buf,
"<machine>%s</machine>\n", caps->machine);
+ virBufferAsprintf(buf, "<arch>%s</arch>\n", arch_str);
+
+ if (caps->maxvcpus)
+ virBufferAsprintf(buf, "<vcpu max='%d'/>\n",
caps->maxvcpus);
+
+ virBufferAddLit(buf, "<devices>\n");
+ virBufferAdjustIndent(buf, 2);
+
+ virDomainCapsDeviceDiskFormat(buf, &caps->disk);
+ virDomainCapsDeviceHostdevFormat(buf, &caps->hostdev);
+
+ virBufferAdjustIndent(buf, -2);
+ virBufferAddLit(buf, "</devices>\n");
+
+ virBufferAdjustIndent(buf, -2);
+ virBufferAddLit(buf, "</domainCapabilities>\n");
+ return 0;
+}
+
+
+char *
+virDomainCapsFormat(virDomainCapsPtr const caps)
+{
+ virBuffer buf = VIR_BUFFER_INITIALIZER;
+
+ if (virDomainCapsFormatInternal(&buf, caps) < 0) {
+ virBufferFreeAndReset(&buf);
+ return NULL;
+ }
+
+ return virBufferContentAndReset(&buf);
+}
diff --git a/src/conf/domain_capabilities.h b/src/conf/domain_capabilities.h
new file mode 100644
index 0000000..731e66f
--- /dev/null
+++ b/src/conf/domain_capabilities.h
@@ -0,0 +1,103 @@
+/*
+ * domain_capabilities.h: domain capabilities XML processing
+ *
+ * Copyright (C) 2014 Red Hat, Inc.
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library. If not, see
+ * <http://www.gnu.org/licenses/>;.
+ *
+ * Author: Michal Privoznik <mprivozn(a)redhat.com>
+ */
+
+#ifndef __DOMAIN_CAPABILITIES_H__
+# define __DOMAIN_CAPABILITIES_H__
+
+# include "internal.h"
+# include "domain_conf.h"
+
+typedef const char * (*virDomainCapsValToStr)(int value);
+
+typedef struct _virDomainCaps virDomainCaps;
+typedef virDomainCaps *virDomainCapsPtr;
+
+typedef struct _virDomainCapsEnum virDomainCapsEnum;
+typedef virDomainCapsEnum *virDomainCapsEnumPtr;
+struct _virDomainCapsEnum {
+ unsigned int values; /* Bitmask of values supported in the corresponding enum */
+};
+
+typedef struct _virDomainCapsDevice virDomainCapsDevice;
+typedef virDomainCapsDevice *virDomainCapsDevicePtr;
+struct _virDomainCapsDevice {
+ bool supported; /* true if <devtype> is supported by hypervisor */
+};
+
+typedef struct _virDomainCapsDeviceDisk virDomainCapsDeviceDisk;
+typedef virDomainCapsDeviceDisk *virDomainCapsDeviceDiskPtr;
+struct _virDomainCapsDeviceDisk {
+ virDomainCapsDevice device;
+ virDomainCapsEnum diskDevice; /* Info about virDomainDiskDevice enum values */
+ virDomainCapsEnum bus; /* Info about virDomainDiskBus enum values */
+ /* add new fields here */
+};
+
+typedef struct _virDomainCapsDeviceHostdev virDomainCapsDeviceHostdev;
+typedef virDomainCapsDeviceHostdev *virDomainCapsDeviceHostdevPtr;
+struct _virDomainCapsDeviceHostdev {
+ virDomainCapsDevice device;
+ virDomainCapsEnum mode; /* Info about virDomainHostdevMode */
+ virDomainCapsEnum startupPolicy; /* Info about virDomainStartupPolicy */
+ virDomainCapsEnum subsysType; /* Info about virDomainHostdevSubsysType */
+ virDomainCapsEnum capsType; /* Info about virDomainHostdevCapsType */
+ virDomainCapsEnum pciBackend; /* Info about
virDomainHostdevSubsysPCIBackendType */
+ /* add new fields here */
+};
Hmm... well maybe I should have read further into the data structures
before making too many comments in the html section :-)
It seems initially it's a very bare bones set of capabilities output. I
guess I had just assumed there was going to be some fun typedef magic
using the Type{To|From}String API's in order to populate the fields.
This is going to be a fairly manual process of adding new elements,
modifying the html, modifying the code, etc.
+
+struct _virDomainCaps {
+ virObjectLockable parent;
+
+ char *path; /* path to emulator binary */
+ virDomainVirtType virttype; /* virtualization type */
+ char *machine; /* machine type */
+ virArch arch; /* domain architecture */
+
+ /* Some machine specific info */
+ int maxvcpus;
+
+ virDomainCapsDeviceDisk disk;
+ virDomainCapsDeviceHostdev hostdev;
+ /* add new domain devices here */
+};
+
+virDomainCapsPtr virDomainCapsNew(const char *path,
+ const char *machine,
+ virArch arch,
+ virDomainVirtType virttype);
+
+# define VIR_DOMAIN_CAPS_ENUM_SET(capsEnum, ...) \
+ do { \
+ unsigned int __values[] = {__VA_ARGS__}; \
+ size_t __nvalues = ARRAY_CARDINALITY(__values); \
+ virDomainCapsEnumSet(&(capsEnum), #capsEnum, \
+ __nvalues, __values); \
+ } while (0)
+
+int virDomainCapsEnumSet(virDomainCapsEnumPtr capsEnum,
+ const char *capsEnumName,
+ size_t nvalues,
+ unsigned int *values);
+void virDomainCapsEnumClear(virDomainCapsEnumPtr capsEnum);
+
+char * virDomainCapsFormat(virDomainCapsPtr const caps);
+#endif /* __DOMAIN_CAPABILITIES_H__ */
diff --git a/src/libvirt_private.syms b/src/libvirt_private.syms
index 1e1dd84..40585bd 100644
--- a/src/libvirt_private.syms
+++ b/src/libvirt_private.syms
@@ -130,6 +130,13 @@ virDomainAuditStop;
virDomainAuditVcpu;
+# conf/domain_capabilities.h
+virDomainCapsEnumClear;
+virDomainCapsEnumSet;
+virDomainCapsFormat;
+virDomainCapsNew;
+
+
# conf/domain_conf.h
virBlkioDeviceArrayClear;
virDiskNameToBusDeviceIndex;
diff --git a/tests/Makefile.am b/tests/Makefile.am
index 025b847..97af0d9 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -74,6 +74,8 @@ EXTRA_DIST = \
commanddata \
confdata \
cputestdata \
+ domaincapsschemadata \
+ domaincapsschematest \
domainconfdata \
domainschemadata \
domainschematest \
@@ -167,6 +169,7 @@ test_programs = virshtest sockettest \
virnetdevbandwidthtest \
virkmodtest \
vircapstest \
+ domaincapstest \
domainconftest \
virhostdevtest \
vircaps2xmltest \
@@ -318,6 +321,7 @@ test_scripts = \
networkschematest \
storagepoolschematest \
storagevolschematest \
+ domaincapsschematest \
domainschematest \
nodedevschematest \
nwfilterschematest \
@@ -827,6 +831,10 @@ vircaps2xmltest_SOURCES = \
vircaps2xmltest.c testutils.h testutils.c
vircaps2xmltest_LDADD = $(LDADDS)
+domaincapstest_SOURCES = \
+ domaincapstest.c testutils.h testutils.c
+domaincapstest_LDADD = $(LDADDS)
+
if WITH_LIBVIRTD
libvirtdconftest_SOURCES = \
libvirtdconftest.c testutils.h testutils.c \
diff --git a/tests/domaincapsschemadata/domaincaps-basic.xml
b/tests/domaincapsschemadata/domaincaps-basic.xml
new file mode 100644
index 0000000..9963519
--- /dev/null
+++ b/tests/domaincapsschemadata/domaincaps-basic.xml
@@ -0,0 +1,10 @@
+<domainCapabilities>
+ <path>/bin/emulatorbin</path>
+ <domain>uml</domain>
+ <machine>my-machine-type</machine>
+ <arch>x86_64</arch>
+ <devices>
+ <disk supported='no'/>
+ <hostdev supported='no'/>
+ </devices>
+</domainCapabilities>
diff --git a/tests/domaincapsschemadata/domaincaps-full.xml
b/tests/domaincapsschemadata/domaincaps-full.xml
new file mode 100644
index 0000000..58dd4cb
--- /dev/null
+++ b/tests/domaincapsschemadata/domaincaps-full.xml
@@ -0,0 +1,56 @@
+<domainCapabilities>
+ <path>/bin/emulatorbin</path>
+ <domain>kvm</domain>
+ <machine>my-machine-type</machine>
+ <arch>x86_64</arch>
+ <vcpu max='255'/>
+ <devices>
+ <disk supported='yes'>
+ <enum name='diskDevice'>
+ <value>disk</value>
+ <value>cdrom</value>
+ <value>floppy</value>
+ <value>lun</value>
+ </enum>
+ <enum name='bus'>
+ <value>ide</value>
+ <value>fdc</value>
+ <value>scsi</value>
+ <value>virtio</value>
+ <value>xen</value>
+ <value>usb</value>
+ <value>uml</value>
+ <value>sata</value>
+ <value>sd</value>
+ </enum>
+ </disk>
+ <hostdev supported='yes'>
+ <enum name='mode'>
+ <value>subsystem</value>
+ <value>capabilities</value>
+ </enum>
+ <enum name='startupPolicy'>
+ <value>default</value>
+ <value>mandatory</value>
+ <value>requisite</value>
+ <value>optional</value>
+ </enum>
+ <enum name='subsysType'>
+ <value>usb</value>
+ <value>pci</value>
+ <value>scsi</value>
+ </enum>
+ <enum name='capsType'>
+ <value>storage</value>
+ <value>misc</value>
+ <value>net</value>
+ </enum>
+ <enum name='pciBackend'>
+ <value>default</value>
+ <value>kvm</value>
+ <value>vfio</value>
+ <value>xen</value>
+ </enum>
+ </hostdev>
+ </devices>
+</domainCapabilities>
diff --git a/tests/domaincapsschematest b/tests/domaincapsschematest
new file mode 100755
index 0000000..9baf44a
--- /dev/null
+++ b/tests/domaincapsschematest
@@ -0,0 +1,11 @@
+#!/bin/sh
+
+: ${srcdir=.}
+. $srcdir/test-lib.sh
+. $abs_srcdir/schematestutils.sh
+
+DIRS=""
+DIRS="$DIRS domaincapsschemadata"
+SCHEMA="domaincaps.rng"
+
+check_schema "$DIRS" "$SCHEMA"
diff --git a/tests/domaincapstest.c b/tests/domaincapstest.c
new file mode 100644
index 0000000..6cdd086
--- /dev/null
+++ b/tests/domaincapstest.c
@@ -0,0 +1,149 @@
+/*
+ * Copyright (C) Red Hat, Inc. 2014
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library. If not, see
+ * <http://www.gnu.org/licenses/>;.
+ *
+ * Authors:
+ * Michal Privoznik <mprivozn(a)redhat.com>
+ */
+
+#include <config.h>
+#include <stdlib.h>
+
+#include "testutils.h"
+#include "domain_capabilities.h"
+
+
+#define VIR_FROM_THIS VIR_FROM_NONE
+
+typedef void (*virDomainCapsFill)(virDomainCapsPtr domCaps,
+ void *opaque);
+
+#define SET_ALL_BITS(x) \
+ memset(&(x.values), 0xff, sizeof(x.values))
+
+static void
+fillAll(virDomainCapsPtr domCaps,
+ void *opaque ATTRIBUTE_UNUSED)
+{
+ virDomainCapsDeviceDiskPtr disk = &domCaps->disk;
+ virDomainCapsDeviceHostdevPtr hostdev = &domCaps->hostdev;
+ domCaps->maxvcpus = 255;
+
+ disk->device.supported = true;
+ SET_ALL_BITS(disk->diskDevice);
+ SET_ALL_BITS(disk->bus);
+
+ hostdev->device.supported = true;
+ SET_ALL_BITS(hostdev->mode);
+ SET_ALL_BITS(hostdev->startupPolicy);
+ SET_ALL_BITS(hostdev->subsysType);
+ SET_ALL_BITS(hostdev->capsType);
+ SET_ALL_BITS(hostdev->pciBackend);
+}
+
+static virDomainCapsPtr
+buildVirDomainCaps(const char *emulatorbin,
+ const char *machine,
+ virArch arch,
+ virDomainVirtType type,
+ virDomainCapsFill fillFunc,
+ void *opaque)
+{
+ virDomainCapsPtr domCaps;
+
+ if (!(domCaps = virDomainCapsNew(emulatorbin, machine, arch, type)))
+ goto cleanup;
+
+ if (fillFunc)
+ fillFunc(domCaps, opaque);
+
+ cleanup:
+ return domCaps;
+}
+
+struct test_virDomainCapsFormatData {
+ const char *filename;
+ const char *emulatorbin;
+ const char *machine;
+ virArch arch;
+ virDomainVirtType type;
+ virDomainCapsFill fillFunc;
+ void *opaque;
+};
+
+static int
+test_virDomainCapsFormat(const void *opaque)
+{
+ struct test_virDomainCapsFormatData *data =
+ (struct test_virDomainCapsFormatData *) opaque;
+ virDomainCapsPtr domCaps = NULL;
+ char *path = NULL;
+ char *domCapsXML = NULL;
+ char *domCapsFromFile = NULL;
+ int ret = -1;
+
+ if (virAsprintf(&path, "%s/domaincapsschemadata/domaincaps-%s.xml",
+ abs_srcdir, data->filename) < 0)
+ goto cleanup;
+
+ if (virFileReadAll(path, 8192, &domCapsFromFile) < 0)
+ goto cleanup;
+
+ if (!(domCaps = buildVirDomainCaps(data->emulatorbin, data->machine,
+ data->arch, data->type,
+ data->fillFunc, data->opaque)))
+ goto cleanup;
+
+ if (!(domCapsXML = virDomainCapsFormat(domCaps)))
+ goto cleanup;
+
+ if (STRNEQ(domCapsFromFile, domCapsXML)) {
+ virtTestDifference(stderr, domCapsFromFile, domCapsXML);
+ goto cleanup;
+ }
+
+ ret = 0;
+ cleanup:
+ VIR_FREE(domCapsFromFile);
+ VIR_FREE(domCapsXML);
+ VIR_FREE(path);
+ virObjectUnref(domCaps);
+ return ret;
+}
+
+static int
+mymain(void)
+{
+ int ret = 0;
+
+#define DO_TEST(Filename, Emulatorbin, Machine, Arch, Type, ...) \
+ do { \
+ struct test_virDomainCapsFormatData data = {.filename = Filename, \
+ .emulatorbin = Emulatorbin, .machine = Machine, .arch = Arch, \
+ .type = Type, __VA_ARGS__}; \
+ if (virtTestRun(Filename, test_virDomainCapsFormat, &data) < 0)
\
+ ret = -1; \
+ } while (0)
+
+ DO_TEST("basic", "/bin/emulatorbin",
"my-machine-type",
+ VIR_ARCH_X86_64, VIR_DOMAIN_VIRT_UML);
+ DO_TEST("full", "/bin/emulatorbin",
"my-machine-type",
+ VIR_ARCH_X86_64, VIR_DOMAIN_VIRT_KVM, .fillFunc = fillAll);
+
+ return ret;
+}
+
+VIRT_TEST_MAIN(mymain)
9:58 a.m.
New subject: [libvirt] [PATCH for 1.2.7 1/8] Introduce domain_capabilities
On Wed, Jul 02, 2014 at 10:32:59AM -0400, John Ferlan wrote:
I was trying to envision use cases - that is how is this expected to
be
used and what "knowledge" is assumed of the caller/user vs. being
designed to a more naive user trying to glean information about what's
available. You have a very specific use case described - can I determine
if vfio is supported, but that requires someone knowing quite a bit of
information that isn't easily accessible unless you read sources or have
a bit of history built up.
For the domcapabilities command that eventually gets added - how does
one know what to provide for the 4 options without knowing a bit about
the environment. It seems the assumption is the user knows to pass
certain elements.
The 'virttype' is pretty easy - that comes from the connection - so I
wonder why it's a parameter to be provided. Does one really have to have
a connection to get the data?
The 'emulatorbin' is less obvious. If it's not passed, there is a way to
get the default value given that you have a virttype, an os type, and an
os arch using virCapabilitiesDefaultGuestEmulator(). What if someone
provides "/usr/bin/qemu-kvm" or "/usr/libexec/qemu-kvm" or is there
an
expectation of /usr/bin/qemu-system-x86_64?
The 'arch' requires a bit more knowledge, but is certainly
"obtainable"
as a default by the current host arch, right? There's also
virCapabilitiesDefaultGuestArch(). However, if someone was looking to
find out what was running on the remote connection (not the local
machine), then that assumption would be incorrect. Seems we should be
able to figure out what arch is associated with the connection.
I think 'machine' is perhaps the most odd to provide; however, like arch
and emulatorbin, there is virCapabilitiesDefaultGuestMachine() to help
you out. For this if one passed "pc" does that work - or do they have
to pass something like "pc-i440fx-1.6" with the next question being how
would they know to generate that?
The valid values for all those parameters are listed in the main
<capabilities> XML under the <guest> sections. The app is of course
free to ask about support for other non-listed values if they have
a custom emulator binary they're passing in.
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 :|
10:01 a.m.
New subject: [libvirt] [PATCH for 1.2.7 1/8] Introduce domain_capabilities
On Wed, Jul 02, 2014 at 10:32:59AM -0400, John Ferlan wrote:
> diff --git a/docs/formatdomaincaps.html.in
b/docs/formatdomaincaps.html.in
> new file mode 100644
> index 0000000..cfd61d9
> --- /dev/null
> +++ b/docs/formatdomaincaps.html.in
Since there's a "Capabilities" page describing the Driver (Host/Guest)
Capabilities and now this one for Domain - do you see a future need for
storage, network, etc. type capabilities? If so, other than the "volume
of data" then why not extend capabilities so that it could list
everything available for everything we know about? e.g.:
<capabilities>
<host... />
<guest... />
<domain... />
<storage... />
<network... />
<interface... />
</capabilities>
Architecturally, does it make sense to merge them or keep then separate?
There seems to be a relationship between them. Furthermore, if the goal
is to just provide information, then using one pile of xml output to
store everything may be useful to someone. For the more seasoned
individual using a specific/directed API that is planned will provide
the directed answer. I think the 'virsh capabilies' output certainly
shows it's possible to grab/use the various arch, machine, emulator, and
domain type values to generate lengthy output listing every possible option.
First we want the <capabilities> XML to keep a reasonable size. If we
listed everything in that one document, it would end up being many
many MB in size. Second, the capabilities XML can only provide info
on the default emulators known to libvirt. The separate API lets us
get info on non-default emulator binaries too.
To your original question though, I do see us adding more APIs in
the future to query info about storage & networking.
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 :|
11:07 a.m.
New subject: [libvirt] [PATCH for 1.2.7 1/8] Introduce domain_capabilities
On 02.07.2014 16:32, John Ferlan wrote:
On 06/30/2014 11:31 AM, Michal Privoznik wrote:
> This new module holds and formats capabilities for emulator. If you
> are about to create a new domain, you may want to know what is the
> host or hypervisor capable of. To make sure we don't regress on the
> XML, the formatting is not something left for each driver to
> implement, rather there's general format function.
>
> The domain capabilities is a lockable object (even though the locking
> is not necessary yet) which uses reference counter.
>
I started looking at these yesterday, but ended up having more questions
than I originally thought I would, so perhaps better to get some
answered. Of course it's already too wordy (sorry)...
I was trying to envision use cases - that is how is this expected to be
used and what "knowledge" is assumed of the caller/user vs. being
designed to a more naive user trying to glean information about what's
available. You have a very specific use case described - can I determine
if vfio is supported, but that requires someone knowing quite a bit of
information that isn't easily accessible unless you read sources or have
a bit of history built up.
Well, that's only for start. Rich already requested some extensions
which will be a follow up patches.
For the domcapabilities command that eventually gets added - how does
one know what to provide for the 4 options without knowing a bit about
the environment. It seems the assumption is the user knows to pass
certain elements.
The 'virttype' is pretty easy - that comes from the connection - so I
wonder why it's a parameter to be provided. Does one really have to have
a connection to get the data?
Consider 'kvm' vs 'qemu'. Or more verbose:
<domain type='kvm'/> vs <domain type='qemu'/>
Both of these are served by qemu:///{system,session} but cannot be
guessed from the connection URI.
The 'emulatorbin' is less obvious. If it's not passed, there is a way to
get the default value given that you have a virttype, an os type, and an
os arch using virCapabilitiesDefaultGuestEmulator(). What if someone
provides "/usr/bin/qemu-kvm" or "/usr/libexec/qemu-kvm" or is there
an
expectation of /usr/bin/qemu-system-x86_64?
Yes, there are several possibilities. Either you'll pass emulatorbin
(which corresponds to <emulator/> in domain XML) or it's defualt value
is guessed from the rest of the arguments. But this is how it works in
qemu. In other drivers it may work differently (once implemented).
The 'arch' requires a bit more knowledge, but is certainly
"obtainable"
as a default by the current host arch, right? There's also
virCapabilitiesDefaultGuestArch(). However, if someone was looking to
find out what was running on the remote connection (not the local
machine), then that assumption would be incorrect. Seems we should be
able to figure out what arch is associated with the connection.
I don't think so. You can run ARM guest on x86_64 machine (where the
connection is to the x86_64 machine and you are querying capabilities
for ARM emulation).
I think 'machine' is perhaps the most odd to provide; however, like arch
and emulatorbin, there is virCapabilitiesDefaultGuestMachine() to help
you out. For this if one passed "pc" does that work - or do they have
to pass something like "pc-i440fx-1.6" with the next question being how
would they know to generate that?
Again, this is something that users may provide, or they can let libvirt
to fill in the sane default. Consider if you want to run, e.g. 'isapc'
(yeah, why would anybody do that? But that's a different story :P).
Reading the domain_conf code - only 'virttype' and 'os_type' really seem
to be required - everything else can be figured out "by default" given
the two.
Correct. That's why the client side of the API checks only for the valid
connection and the rest of the checks is left for drivers to implement,
since (in general) different drivers have different sets of minimal
arguments required.
Having (a) virsh command(s) to display possible options may be
a nice addition, especially for the naive user... Should be very easy
to
add something that could print out the virArch options. Leaving only the
need to know what the os_type is before behing able to at least fetch
defaults and generate XML output. Perhaps someone just using "virsh
domcapabilities" would print out tables of all arch's.. Similarly if
arch was provided, then print out all emulatorbin's (if that's possible)
for the arch or just the default emulatorbin... Given an arch and
emulatorbin, then print out the machines available.
Sure, virsh user friendliness is not something I'm so proud of. But I
have nothing else to say that "patches are welcome". I mean, there are
other commands that take string values that only XML struct aware user
knows about: attach-disk is rich of examples (--driver, --cache, ...)
Michal
12:19 p.m.
New subject: [libvirt] [PATCH for 1.2.7 1/8] Introduce domain_capabilities
On 07/02/2014 12:07 PM, Michal Privoznik wrote:
On 02.07.2014 16:32, John Ferlan wrote:
>
>
> On 06/30/2014 11:31 AM, Michal Privoznik wrote:
>> This new module holds and formats capabilities for emulator. If you
>> are about to create a new domain, you may want to know what is the
>> host or hypervisor capable of. To make sure we don't regress on the
>> XML, the formatting is not something left for each driver to
>> implement, rather there's general format function.
>>
>> The domain capabilities is a lockable object (even though the locking
>> is not necessary yet) which uses reference counter.
>>
>
> I started looking at these yesterday, but ended up having more questions
> than I originally thought I would, so perhaps better to get some
> answered. Of course it's already too wordy (sorry)...
>
> I was trying to envision use cases - that is how is this expected to be
> used and what "knowledge" is assumed of the caller/user vs. being
> designed to a more naive user trying to glean information about what's
> available. You have a very specific use case described - can I determine
> if vfio is supported, but that requires someone knowing quite a bit of
> information that isn't easily accessible unless you read sources or have
> a bit of history built up.
Well, that's only for start. Rich already requested some extensions
which will be a follow up patches.
I saw those in the original RFC posting and I see Dan updated the bz to
point at the RFC that resulted in this series...
>
> For the domcapabilities command that eventually gets added - how does
> one know what to provide for the 4 options without knowing a bit about
> the environment. It seems the assumption is the user knows to pass
> certain elements.
>
> The 'virttype' is pretty easy - that comes from the connection - so I
> wonder why it's a parameter to be provided. Does one really have to have
> a connection to get the data?
Consider 'kvm' vs 'qemu'. Or more verbose:
<domain type='kvm'/> vs <domain type='qemu'/>
Both of these are served by qemu:///{system,session} but cannot be
guessed from the connection URI.
oh yeah - right... And if I supply "kvm" or "qemu", both will use
the
qemu_driver.c code to resolve defaults for emulatorbin, arch, and
machine right? To that degree they're synonyms. It's only when filling
in the details of the domaincaps from qemucaps does it matter.
>
> The 'emulatorbin' is less obvious. If it's not passed, there is a way to
> get the default value given that you have a virttype, an os type, and an
> os arch using virCapabilitiesDefaultGuestEmulator(). What if someone
> provides "/usr/bin/qemu-kvm" or "/usr/libexec/qemu-kvm" or is
there an
> expectation of /usr/bin/qemu-system-x86_64?
Yes, there are several possibilities. Either you'll pass emulatorbin
(which corresponds to <emulator/> in domain XML) or it's defualt value
is guessed from the rest of the arguments. But this is how it works in
qemu. In other drivers it may work differently (once implemented).
Right - understood it's in the domain, but if you don't have a domain,
you still may not know what to provide. The qemu driver code expects
you to pass either "arch" or "emulator" in order to provide anything.
So you have to know one or the other to get something and the only place
to get that would then be the virsh capabilities output which I figured
out after I'd written most of the original response.
>
> The 'arch' requires a bit more knowledge, but is certainly
"obtainable"
> as a default by the current host arch, right? There's also
> virCapabilitiesDefaultGuestArch(). However, if someone was looking to
> find out what was running on the remote connection (not the local
> machine), then that assumption would be incorrect. Seems we should be
> able to figure out what arch is associated with the connection.
I don't think so. You can run ARM guest on x86_64 machine (where the
connection is to the x86_64 machine and you are querying capabilities
for ARM emulation).
So again - you have to know emulator or arch for qemu and that is
fetched from virsh capabilities - something that could be at least
documented. That is - how to figure what to pass to virsh
domcapabilities... (something that gets more difficult to type every
time I type it :-) - "domcaps" is so much easier...)
>
> I think 'machine' is perhaps the most odd to provide; however, like arch
> and emulatorbin, there is virCapabilitiesDefaultGuestMachine() to help
> you out. For this if one passed "pc" does that work - or do they have
> to pass something like "pc-i440fx-1.6" with the next question being how
> would they know to generate that?
Again, this is something that users may provide, or they can let libvirt
to fill in the sane default. Consider if you want to run, e.g. 'isapc'
(yeah, why would anybody do that? But that's a different story :P).
Right and it's not clear what has to be provided until one runs the
command for the 'virttype'...
>
> Reading the domain_conf code - only 'virttype' and 'os_type' really
seem
> to be required - everything else can be figured out "by default" given
> the two.
Correct. That's why the client side of the API checks only for the valid
connection and the rest of the checks is left for drivers to implement,
since (in general) different drivers have different sets of minimal
arguments required.
The piece of the puzzle that's missing from the descriptions -
user/customer has to start somewhere though.
Having (a) virsh command(s) to display possible options may be
> a nice addition, especially for the naive user... Should be very easy to
> add something that could print out the virArch options. Leaving only the
> need to know what the os_type is before behing able to at least fetch
> defaults and generate XML output. Perhaps someone just using "virsh
> domcapabilities" would print out tables of all arch's.. Similarly if
> arch was provided, then print out all emulatorbin's (if that's possible)
> for the arch or just the default emulatorbin... Given an arch and
> emulatorbin, then print out the machines available.
Sure, virsh user friendliness is not something I'm so proud of. But I
have nothing else to say that "patches are welcome". I mean, there are
other commands that take string values that only XML struct aware user
knows about: attach-disk is rich of examples (--driver, --cache, ...)
Right/Understood - there are certainly other examples where figuring out
the right incantation to use can be a challenge. This change is like a
gift that keeps giving in order to hopefully one day catch up to
everything that's currently supported and then "require it" (by some
rule) for anything added.
The series does scratch an itch to solve a specific problem - knowing
whether vfio is supported or not for a specific virttype, arch, machine,
and emulator, but it also opens Pandora's box of never ending requests
to display some specific feature someone is interested in.
Yes, like you note - patches are welcome... Still need to understand
the vision so that patches are useful... For instance if a "--list"
option was added to essentially print everything that we knew about
based on what was in virsh capabilities...
I'm not opposed to the patches and you have Dan's ACK - my only hope is
a clearer understanding of what's there now and what's expected.
Documenting that using the virsh capabilities output to find the various
values wasn't clear to me until I started poking around. I don't mind
helping with the language/documentation aspects of it - just want to be
sure I have a better picture of what I'm trying to describe!
John
10:31 a.m.
New subject: [libvirt] [PATCH for 1.2.7 2/8] Introduce virConnectGetDomainCapabilities
The API should expose the information contained in virDomainCapsPtr.
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
---
include/libvirt/libvirt.h.in | 7 ++++++
src/driver.h | 9 ++++++++
src/libvirt.c | 52 ++++++++++++++++++++++++++++++++++++++++++++
src/libvirt_public.syms | 5 +++++
src/remote/remote_driver.c | 1 +
src/remote/remote_protocol.x | 19 +++++++++++++++-
src/remote_protocol-structs | 11 ++++++++++
7 files changed, 103 insertions(+), 1 deletion(-)
diff --git a/include/libvirt/libvirt.h.in b/include/libvirt/libvirt.h.in
index 032d6e6..aedd49a 100644
--- a/include/libvirt/libvirt.h.in
+++ b/include/libvirt/libvirt.h.in
@@ -1585,6 +1585,13 @@ int virNodeGetInfo (virConnectPtr
conn,
virNodeInfoPtr info);
char * virConnectGetCapabilities (virConnectPtr conn);
+char * virConnectGetDomainCapabilities(virConnectPtr conn,
+ const char *emulatorbin,
+ const char *arch,
+ const char *machine,
+ const char *virttype,
+ unsigned int flags);
+
int virNodeGetCPUStats (virConnectPtr conn,
int cpuNum,
virNodeCPUStatsPtr params,
diff --git a/src/driver.h b/src/driver.h
index 5018068..c769675 100644
--- a/src/driver.h
+++ b/src/driver.h
@@ -126,6 +126,14 @@ typedef int
typedef char *
(*virDrvConnectGetCapabilities)(virConnectPtr conn);
+typedef char *
+(*virDrvConnectGetDomainCapabilities)(virConnectPtr conn,
+ const char *emulatorbin,
+ const char *arch,
+ const char *machine,
+ const char *virttype,
+ unsigned int flags);
+
typedef int
(*virDrvConnectListDomains)(virConnectPtr conn,
int *ids,
@@ -1407,6 +1415,7 @@ struct _virDriver {
virDrvDomainGetTime domainGetTime;
virDrvDomainSetTime domainSetTime;
virDrvNodeGetFreePages nodeGetFreePages;
+ virDrvConnectGetDomainCapabilities connectGetDomainCapabilities;
};
diff --git a/src/libvirt.c b/src/libvirt.c
index 88c1f49..3511b1b 100644
--- a/src/libvirt.c
+++ b/src/libvirt.c
@@ -21137,3 +21137,55 @@ virNetworkDHCPLeaseFree(virNetworkDHCPLeasePtr lease)
VIR_FREE(lease->clientid);
VIR_FREE(lease);
}
+
+/**
+ * virConnectGetDomainCapabilities:
+ * @conn: pointer to the hypervisor connection
+ * @emulatorbin: path to emulator
+ * @arch: domain architecture
+ * @machine: machine type
+ * @virttype: virtualization type
+ * @flags: extra flags; not used yet, so callers should always pass 0
+ *
+ * Prior creating a domain (for instance via virDomainCreateXML
+ * or virDomainDefineXML) it may be suitable to know what the
+ * underlying emulator and/or libvirt is capable of. For
+ * instance, if host, libvirt and qemu is capable of VFIO
+ * passthrough and so on.
+ *
+ * Returns NULL in case of error, or an XML string
+ * defining the capabilities.
+ */
+char *
+virConnectGetDomainCapabilities(virConnectPtr conn,
+ const char *emulatorbin,
+ const char *arch,
+ const char *machine,
+ const char *virttype,
+ unsigned int flags)
+{
+ VIR_DEBUG("conn=%p, emulatorbin=%s, arch=%s, "
+ "machine=%s, virttype=%s, flags=%x",
+ conn, emulatorbin, arch, machine, virttype, flags);
+
+ virResetLastError();
+
+ virCheckConnectReturn(conn, NULL);
+
+ if (conn->driver->connectGetDomainCapabilities) {
+ char *ret;
+ ret = conn->driver->connectGetDomainCapabilities(conn, emulatorbin,
+ arch, machine,
+ virttype, flags);
+ if (!ret)
+ goto error;
+ VIR_DEBUG("conn=%p, ret=%s", conn, ret);
+ return ret;
+ }
+
+ virReportUnsupportedError();
+
+ error:
+ virDispatchError(conn);
+ return NULL;
+}
diff --git a/src/libvirt_public.syms b/src/libvirt_public.syms
index 65a5b43..9f4016a 100644
--- a/src/libvirt_public.syms
+++ b/src/libvirt_public.syms
@@ -665,4 +665,9 @@ LIBVIRT_1.2.6 {
virNetworkGetDHCPLeases;
} LIBVIRT_1.2.5;
+LIBVIRT_1.2.7 {
+ global:
+ virConnectGetDomainCapabilities;
+} LIBVIRT_1.2.6;
+
# .... define new API here using predicted next version number ....
diff --git a/src/remote/remote_driver.c b/src/remote/remote_driver.c
index 3c10d5c..88fc977 100644
--- a/src/remote/remote_driver.c
+++ b/src/remote/remote_driver.c
@@ -8004,6 +8004,7 @@ static virDriver remote_driver = {
.domainGetTime = remoteDomainGetTime, /* 1.2.5 */
.domainSetTime = remoteDomainSetTime, /* 1.2.5 */
.nodeGetFreePages = remoteNodeGetFreePages, /* 1.2.6 */
+ .connectGetDomainCapabilities = remoteConnectGetDomainCapabilities, /* 1.2.7 */
};
static virNetworkDriver network_driver = {
diff --git a/src/remote/remote_protocol.x b/src/remote/remote_protocol.x
index bff2c47..5c316fb 100644
--- a/src/remote/remote_protocol.x
+++ b/src/remote/remote_protocol.x
@@ -478,6 +478,18 @@ struct remote_connect_get_capabilities_ret {
remote_nonnull_string capabilities;
};
+struct remote_connect_get_domain_capabilities_args {
+ remote_string emulatorbin;
+ remote_string arch;
+ remote_string machine;
+ remote_string virttype;
+ unsigned int flags;
+};
+
+struct remote_connect_get_domain_capabilities_ret {
+ remote_nonnull_string capabilities;
+};
+
struct remote_node_get_cpu_stats_args {
int cpuNum;
int nparams;
@@ -5402,6 +5414,11 @@ enum remote_procedure {
* @generate: none
* @acl: network:read
*/
- REMOTE_PROC_NETWORK_GET_DHCP_LEASES = 341
+ REMOTE_PROC_NETWORK_GET_DHCP_LEASES = 341,
+ /**
+ * @generate: both
+ * @acl: connect:write
+ */
+ REMOTE_PROC_CONNECT_GET_DOMAIN_CAPABILITIES = 342
};
diff --git a/src/remote_protocol-structs b/src/remote_protocol-structs
index a14e1fd..9bf09b8 100644
--- a/src/remote_protocol-structs
+++ b/src/remote_protocol-structs
@@ -148,6 +148,16 @@ struct remote_node_get_info_ret {
struct remote_connect_get_capabilities_ret {
remote_nonnull_string capabilities;
};
+struct remote_connect_get_domain_capabilities_args {
+ remote_string emulatorbin;
+ remote_string arch;
+ remote_string machine;
+ remote_string virttype;
+ u_int flags;
+};
+struct remote_connect_get_domain_capabilities_ret {
+ remote_nonnull_string capabilities;
+};
struct remote_node_get_cpu_stats_args {
int cpuNum;
int nparams;
@@ -2851,4 +2861,5 @@ enum remote_procedure {
REMOTE_PROC_DOMAIN_EVENT_BLOCK_JOB_2 = 339,
REMOTE_PROC_NODE_GET_FREE_PAGES = 340,
REMOTE_PROC_NETWORK_GET_DHCP_LEASES = 341,
+ REMOTE_PROC_CONNECT_GET_DOMAIN_CAPABILITIES = 342,
};
--
1.8.5.5
9:29 a.m.
New subject: [libvirt] [PATCH for 1.2.7 2/8] Introduce virConnectGetDomainCapabilities
On Mon, Jun 30, 2014 at 05:31:45PM +0200, Michal Privoznik wrote:
The API should expose the information contained in virDomainCapsPtr.
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
---
include/libvirt/libvirt.h.in | 7 ++++++
src/driver.h | 9 ++++++++
src/libvirt.c | 52 ++++++++++++++++++++++++++++++++++++++++++++
src/libvirt_public.syms | 5 +++++
src/remote/remote_driver.c | 1 +
src/remote/remote_protocol.x | 19 +++++++++++++++-
src/remote_protocol-structs | 11 ++++++++++
7 files changed, 103 insertions(+), 1 deletion(-)
ACK
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 :|
9:41 a.m.
New subject: [libvirt] [PATCH for 1.2.7 2/8] Introduce virConnectGetDomainCapabilities
On 06/30/2014 11:31 AM, Michal Privoznik wrote:
The API should expose the information contained in virDomainCapsPtr.
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
---
include/libvirt/libvirt.h.in | 7 ++++++
src/driver.h | 9 ++++++++
src/libvirt.c | 52 ++++++++++++++++++++++++++++++++++++++++++++
src/libvirt_public.syms | 5 +++++
src/remote/remote_driver.c | 1 +
src/remote/remote_protocol.x | 19 +++++++++++++++-
src/remote_protocol-structs | 11 ++++++++++
7 files changed, 103 insertions(+), 1 deletion(-)
diff --git a/include/libvirt/libvirt.h.in b/include/libvirt/libvirt.h.in
index 032d6e6..aedd49a 100644
--- a/include/libvirt/libvirt.h.in
+++ b/include/libvirt/libvirt.h.in
@@ -1585,6 +1585,13 @@ int virNodeGetInfo (virConnectPtr
conn,
virNodeInfoPtr info);
char * virConnectGetCapabilities (virConnectPtr conn);
+char * virConnectGetDomainCapabilities(virConnectPtr conn,
+ const char *emulatorbin,
+ const char *arch,
+ const char *machine,
+ const char *virttype,
+ unsigned int flags);
+
int virNodeGetCPUStats (virConnectPtr conn,
int cpuNum,
virNodeCPUStatsPtr params,
diff --git a/src/driver.h b/src/driver.h
index 5018068..c769675 100644
--- a/src/driver.h
+++ b/src/driver.h
@@ -126,6 +126,14 @@ typedef int
typedef char *
(*virDrvConnectGetCapabilities)(virConnectPtr conn);
+typedef char *
+(*virDrvConnectGetDomainCapabilities)(virConnectPtr conn,
+ const char *emulatorbin,
+ const char *arch,
+ const char *machine,
+ const char *virttype,
+ unsigned int flags);
+
typedef int
(*virDrvConnectListDomains)(virConnectPtr conn,
int *ids,
@@ -1407,6 +1415,7 @@ struct _virDriver {
virDrvDomainGetTime domainGetTime;
virDrvDomainSetTime domainSetTime;
virDrvNodeGetFreePages nodeGetFreePages;
+ virDrvConnectGetDomainCapabilities connectGetDomainCapabilities;
};
diff --git a/src/libvirt.c b/src/libvirt.c
index 88c1f49..3511b1b 100644
--- a/src/libvirt.c
+++ b/src/libvirt.c
@@ -21137,3 +21137,55 @@ virNetworkDHCPLeaseFree(virNetworkDHCPLeasePtr lease)
VIR_FREE(lease->clientid);
VIR_FREE(lease);
}
+
+/**
+ * virConnectGetDomainCapabilities:
+ * @conn: pointer to the hypervisor connection
+ * @emulatorbin: path to emulator
+ * @arch: domain architecture
+ * @machine: machine type
+ * @virttype: virtualization type
+ * @flags: extra flags; not used yet, so callers should always pass 0
+ *
+ * Prior creating a domain (for instance via virDomainCreateXML
+ * or virDomainDefineXML) it may be suitable to know what the
+ * underlying emulator and/or libvirt is capable of. For
+ * instance, if host, libvirt and qemu is capable of VFIO
+ * passthrough and so on.
+ *
+ * Returns NULL in case of error, or an XML string
s/error,/error/
FWIW: Use of the comma in this construct "looks odd" as if there was
some third option. Think of it this way "a or b" or "a, b, or c"
where
the comma is added in the second construct to separate list elements.
Seems the rest is right to me - although I guess the answer to whether
NULL is "expected" or not is something that needs to be answered before
there's an ACK.
John
+ * defining the capabilities.
+ */
+char *
+virConnectGetDomainCapabilities(virConnectPtr conn,
+ const char *emulatorbin,
+ const char *arch,
+ const char *machine,
+ const char *virttype,
+ unsigned int flags)
+{
+ VIR_DEBUG("conn=%p, emulatorbin=%s, arch=%s, "
+ "machine=%s, virttype=%s, flags=%x",
+ conn, emulatorbin, arch, machine, virttype, flags);
+
There's nothing that's stopping someone from passing NULL for
emulatorbin, arch, machine, & virttype...
+ virResetLastError();
+
+ virCheckConnectReturn(conn, NULL);
+
+ if (conn->driver->connectGetDomainCapabilities) {
+ char *ret;
+ ret = conn->driver->connectGetDomainCapabilities(conn, emulatorbin,
+ arch, machine,
+ virttype, flags);
+ if (!ret)
+ goto error;
+ VIR_DEBUG("conn=%p, ret=%s", conn, ret);
+ return ret;
+ }
+
+ virReportUnsupportedError();
+
+ error:
+ virDispatchError(conn);
+ return NULL;
+}
diff --git a/src/libvirt_public.syms b/src/libvirt_public.syms
index 65a5b43..9f4016a 100644
--- a/src/libvirt_public.syms
+++ b/src/libvirt_public.syms
@@ -665,4 +665,9 @@ LIBVIRT_1.2.6 {
virNetworkGetDHCPLeases;
} LIBVIRT_1.2.5;
+LIBVIRT_1.2.7 {
+ global:
+ virConnectGetDomainCapabilities;
+} LIBVIRT_1.2.6;
+
# .... define new API here using predicted next version number ....
diff --git a/src/remote/remote_driver.c b/src/remote/remote_driver.c
index 3c10d5c..88fc977 100644
--- a/src/remote/remote_driver.c
+++ b/src/remote/remote_driver.c
@@ -8004,6 +8004,7 @@ static virDriver remote_driver = {
.domainGetTime = remoteDomainGetTime, /* 1.2.5 */
.domainSetTime = remoteDomainSetTime, /* 1.2.5 */
.nodeGetFreePages = remoteNodeGetFreePages, /* 1.2.6 */
+ .connectGetDomainCapabilities = remoteConnectGetDomainCapabilities, /* 1.2.7 */
};
static virNetworkDriver network_driver = {
diff --git a/src/remote/remote_protocol.x b/src/remote/remote_protocol.x
index bff2c47..5c316fb 100644
--- a/src/remote/remote_protocol.x
+++ b/src/remote/remote_protocol.x
@@ -478,6 +478,18 @@ struct remote_connect_get_capabilities_ret {
remote_nonnull_string capabilities;
};
+struct remote_connect_get_domain_capabilities_args {
+ remote_string emulatorbin;
+ remote_string arch;
+ remote_string machine;
+ remote_string virttype;
+ unsigned int flags;
+};
+
+struct remote_connect_get_domain_capabilities_ret {
+ remote_nonnull_string capabilities;
+};
+
struct remote_node_get_cpu_stats_args {
int cpuNum;
int nparams;
@@ -5402,6 +5414,11 @@ enum remote_procedure {
* @generate: none
* @acl: network:read
*/
- REMOTE_PROC_NETWORK_GET_DHCP_LEASES = 341
+ REMOTE_PROC_NETWORK_GET_DHCP_LEASES = 341,
+ /**
+ * @generate: both
+ * @acl: connect:write
+ */
+ REMOTE_PROC_CONNECT_GET_DOMAIN_CAPABILITIES = 342
};
diff --git a/src/remote_protocol-structs b/src/remote_protocol-structs
index a14e1fd..9bf09b8 100644
--- a/src/remote_protocol-structs
+++ b/src/remote_protocol-structs
@@ -148,6 +148,16 @@ struct remote_node_get_info_ret {
struct remote_connect_get_capabilities_ret {
remote_nonnull_string capabilities;
};
+struct remote_connect_get_domain_capabilities_args {
+ remote_string emulatorbin;
+ remote_string arch;
+ remote_string machine;
+ remote_string virttype;
+ u_int flags;
+};
+struct remote_connect_get_domain_capabilities_ret {
+ remote_nonnull_string capabilities;
+};
struct remote_node_get_cpu_stats_args {
int cpuNum;
int nparams;
@@ -2851,4 +2861,5 @@ enum remote_procedure {
REMOTE_PROC_DOMAIN_EVENT_BLOCK_JOB_2 = 339,
REMOTE_PROC_NODE_GET_FREE_PAGES = 340,
REMOTE_PROC_NETWORK_GET_DHCP_LEASES = 341,
+ REMOTE_PROC_CONNECT_GET_DOMAIN_CAPABILITIES = 342,
};
10:31 a.m.
New subject: [libvirt] [PATCH for 1.2.7 3/8] virsh: expose virConnectGetDomainCapabilities
The API is exposed under 'domcapabilities' command. Currently, with
the variety of drivers that libvirt supports, none of the command
arguments is obligatory, but all are optional instead.
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
---
tools/virsh-host.c | 84 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
tools/virsh.pod | 16 +++++++++++
2 files changed, 100 insertions(+)
diff --git a/tools/virsh-host.c b/tools/virsh-host.c
index 734f1a8..a1d8465 100644
--- a/tools/virsh-host.c
+++ b/tools/virsh-host.c
@@ -69,6 +69,84 @@ cmdCapabilities(vshControl *ctl, const vshCmd *cmd ATTRIBUTE_UNUSED)
}
/*
+ * "domcapabilities" command
+ */
+static const vshCmdInfo info_domcapabilities[] = {
+ {.name = "help",
+ .data = N_("domain capabilities")
+ },
+ {.name = "desc",
+ .data = N_("Returns capabilities of emulator with respect to host and
libvirt.")
+ },
+ {.name = NULL}
+};
+
+static const vshCmdOptDef opts_domcapabilities[] = {
+ {.name = "virttype",
+ .type = VSH_OT_STRING,
+ .help = N_("virtualization type (/domain/@type)"),
+ },
+ {.name = "emulatorbin",
+ .type = VSH_OT_STRING,
+ .help = N_("path to emulator binary (/domain/devices/emulator)"),
+ },
+ {.name = "arch",
+ .type = VSH_OT_STRING,
+ .help = N_("domain architecture (/domain/os/type/@arch)"),
+ },
+ {.name = "machine",
+ .type = VSH_OT_STRING,
+ .help = N_("machine type (/domain/os/type/@machine)"),
+ },
+ {.name = NULL}
+};
+
+static bool
+cmdDomCapabilities(vshControl *ctl, const vshCmd *cmd)
+{
+ bool ret = false;
+ char *caps;
+ const char *virttype = NULL;
+ const char *emulatorbin = NULL;
+ const char *arch = NULL;
+ const char *machine = NULL;
+ const unsigned int flags = 0; /* No flags so far */
+
+ if (vshCommandOptString(cmd, "virttype", &virttype) < 0) {
+ vshError(ctl, "%s", _("ble"));
+ goto cleanup;
+ }
+
+ if (vshCommandOptString(cmd, "emulatorbin", &emulatorbin) < 0) {
+ vshError(ctl, "%s", _("ble"));
+ goto cleanup;
+ }
+
+ if (vshCommandOptString(cmd, "arch", &arch) < 0) {
+ vshError(ctl, "%s", _("ble"));
+ goto cleanup;
+ }
+
+ if (vshCommandOptString(cmd, "machine", &machine) < 0) {
+ vshError(ctl, "%s", _("ble"));
+ goto cleanup;
+ }
+
+ caps = virConnectGetDomainCapabilities(ctl->conn, emulatorbin,
+ arch, machine, virttype, flags);
+ if (!caps) {
+ vshError(ctl, "%s", _("failed to get emulator
capabilities"));
+ goto cleanup;
+ }
+
+ vshPrint(ctl, "%s\n", caps);
+ ret = true;
+ cleanup:
+ VIR_FREE(caps);
+ return ret;
+}
+
+/*
* "freecell" command
*/
static const vshCmdInfo info_freecell[] = {
@@ -1131,6 +1209,12 @@ const vshCmdDef hostAndHypervisorCmds[] = {
.info = info_cpu_models,
.flags = 0
},
+ {.name = "domcapabilities",
+ .handler = cmdDomCapabilities,
+ .opts = opts_domcapabilities,
+ .info = info_domcapabilities,
+ .flags = 0
+ },
{.name = "freecell",
.handler = cmdFreecell,
.opts = opts_freecell,
diff --git a/tools/virsh.pod b/tools/virsh.pod
index b248c9a..b37a2be 100644
--- a/tools/virsh.pod
+++ b/tools/virsh.pod
@@ -350,6 +350,22 @@ description see:
L<http://libvirt.org/formatcaps.html>
The XML also show the NUMA topology information if available.
+=item B<domcapabilities> [I<virttype>] [I<emulatorbin>]
+[I<arch>] [I<machine>]
+
+Print an XML document describing the capabilities of the
+hypervisor we are currently connected to. This may be useful if
+you intend to create a new domain and are curious if for instance
+should use VFIO or legacy KVM device passthrough. The I<virttype>
+specifies the virtualization used (the domain XML counterpart is
+the 'type' attribute of the <domain/> top level element). Then,
+the I<emulatorbin> specifies the path to the emulator (this is
+same as <emulator> element in the domain XML). Then, the I<arch>
+argument sets the domain architecture (exposed under
+/domain/os/type/@arch attribute). Then at last I<machine>
+overrides the default machine for the emulator (can be found in
+domain XML under /domain/os/type).
+
=item B<inject-nmi> I<domain>
Inject NMI to the guest.
--
1.8.5.5
9:47 a.m.
New subject: [libvirt] [PATCH for 1.2.7 3/8] virsh: expose virConnectGetDomainCapabilities
On Mon, Jun 30, 2014 at 05:31:46PM +0200, Michal Privoznik wrote:
The API is exposed under 'domcapabilities' command.
Currently, with
the variety of drivers that libvirt supports, none of the command
arguments is obligatory, but all are optional instead.
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
---
tools/virsh-host.c | 84 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
tools/virsh.pod | 16 +++++++++++
2 files changed, 100 insertions(+)
ACK
+static bool
+cmdDomCapabilities(vshControl *ctl, const vshCmd *cmd)
+{
+ bool ret = false;
+ char *caps;
+ const char *virttype = NULL;
+ const char *emulatorbin = NULL;
+ const char *arch = NULL;
+ const char *machine = NULL;
+ const unsigned int flags = 0; /* No flags so far */
+
+ if (vshCommandOptString(cmd, "virttype", &virttype) < 0) {
+ vshError(ctl, "%s", _("ble"));
I imagine "ble" was a placeholder you meant to replace :-)
+ goto cleanup;
+ }
+
+ if (vshCommandOptString(cmd, "emulatorbin", &emulatorbin) < 0) {
+ vshError(ctl, "%s", _("ble"));
+ goto cleanup;
+ }
+
+ if (vshCommandOptString(cmd, "arch", &arch) < 0) {
+ vshError(ctl, "%s", _("ble"));
+ goto cleanup;
+ }
+
+ if (vshCommandOptString(cmd, "machine", &machine) < 0) {
+ vshError(ctl, "%s", _("ble"));
+ goto cleanup;
+ }
ACK if that is fixed.
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 :|
9:51 a.m.
New subject: [libvirt] [PATCH for 1.2.7 3/8] virsh: expose virConnectGetDomainCapabilities
On 06/30/2014 11:31 AM, Michal Privoznik wrote:
The API is exposed under 'domcapabilities' command.
Currently, with
the variety of drivers that libvirt supports, none of the command
arguments is obligatory, but all are optional instead.
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
---
tools/virsh-host.c | 84 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
tools/virsh.pod | 16 +++++++++++
2 files changed, 100 insertions(+)
diff --git a/tools/virsh-host.c b/tools/virsh-host.c
index 734f1a8..a1d8465 100644
--- a/tools/virsh-host.c
+++ b/tools/virsh-host.c
@@ -69,6 +69,84 @@ cmdCapabilities(vshControl *ctl, const vshCmd *cmd ATTRIBUTE_UNUSED)
}
/*
+ * "domcapabilities" command
+ */
+static const vshCmdInfo info_domcapabilities[] = {
+ {.name = "help",
+ .data = N_("domain capabilities")
+ },
+ {.name = "desc",
+ .data = N_("Returns capabilities of emulator with respect to host and
libvirt.")
+ },
+ {.name = NULL}
+};
+
+static const vshCmdOptDef opts_domcapabilities[] = {
+ {.name = "virttype",
+ .type = VSH_OT_STRING,
+ .help = N_("virtualization type (/domain/@type)"),
+ },
+ {.name = "emulatorbin",
+ .type = VSH_OT_STRING,
+ .help = N_("path to emulator binary (/domain/devices/emulator)"),
+ },
+ {.name = "arch",
+ .type = VSH_OT_STRING,
+ .help = N_("domain architecture (/domain/os/type/@arch)"),
+ },
+ {.name = "machine",
+ .type = VSH_OT_STRING,
+ .help = N_("machine type (/domain/os/type/@machine)"),
+ },
+ {.name = NULL}
+};
+
+static bool
+cmdDomCapabilities(vshControl *ctl, const vshCmd *cmd)
+{
+ bool ret = false;
+ char *caps;
+ const char *virttype = NULL;
+ const char *emulatorbin = NULL;
+ const char *arch = NULL;
+ const char *machine = NULL;
+ const unsigned int flags = 0; /* No flags so far */
+
+ if (vshCommandOptString(cmd, "virttype", &virttype) < 0) {
+ vshError(ctl, "%s", _("ble"));
+ goto cleanup;
+ }
+
+ if (vshCommandOptString(cmd, "emulatorbin", &emulatorbin) < 0) {
+ vshError(ctl, "%s", _("ble"));
+ goto cleanup;
+ }
+
+ if (vshCommandOptString(cmd, "arch", &arch) < 0) {
+ vshError(ctl, "%s", _("ble"));
+ goto cleanup;
+ }
+
+ if (vshCommandOptString(cmd, "machine", &machine) < 0) {
+ vshError(ctl, "%s", _("ble"));
+ goto cleanup;
+ }
None of the above have realistic error messages. If they're not found on
the command line, then how should things proceed?
Although the code in the qemu driver seems to only care that virttype is
provided. The qemu driver also requires arch or emulatorbin to be
provided in order to fetch machine (and other caps).
+
+ caps = virConnectGetDomainCapabilities(ctl->conn, emulatorbin,
+ arch, machine, virttype, flags);
+ if (!caps) {
+ vshError(ctl, "%s", _("failed to get emulator
capabilities"));
+ goto cleanup;
+ }
+
+ vshPrint(ctl, "%s\n", caps);
+ ret = true;
+ cleanup:
+ VIR_FREE(caps);
+ return ret;
+}
+
+/*
* "freecell" command
*/
static const vshCmdInfo info_freecell[] = {
@@ -1131,6 +1209,12 @@ const vshCmdDef hostAndHypervisorCmds[] = {
.info = info_cpu_models,
.flags = 0
},
+ {.name = "domcapabilities",
+ .handler = cmdDomCapabilities,
+ .opts = opts_domcapabilities,
+ .info = info_domcapabilities,
+ .flags = 0
+ },
{.name = "freecell",
.handler = cmdFreecell,
.opts = opts_freecell,
diff --git a/tools/virsh.pod b/tools/virsh.pod
index b248c9a..b37a2be 100644
--- a/tools/virsh.pod
+++ b/tools/virsh.pod
@@ -350,6 +350,22 @@ description see:
L<http://libvirt.org/formatcaps.html>
The XML also show the NUMA topology information if available.
+=item B<domcapabilities> [I<virttype>] [I<emulatorbin>]
+[I<arch>] [I<machine>]
+
+Print an XML document describing the capabilities of the
+hypervisor we are currently connected to. This may be useful if
+you intend to create a new domain and are curious if for instance
+should use VFIO or legacy KVM device passthrough. The I<virttype>
+specifies the virtualization used (the domain XML counterpart is
+the 'type' attribute of the <domain/> top level element). Then,
+the I<emulatorbin> specifies the path to the emulator (this is
+same as <emulator> element in the domain XML). Then, the I<arch>
+argument sets the domain architecture (exposed under
+/domain/os/type/@arch attribute). Then at last I<machine>
+overrides the default machine for the emulator (can be found in
+domain XML under /domain/os/type).
+
From just the description, I would think I could get all the caps for
the domain of the hypervisor that virsh is connected to. Although I
still have to provide the virttype (which should be part of the
connection right)? I guess this goes along with my comments from patch
1 about not having a clear enough picture yet to know the best way to
describe the virsh.pod fields.
Once that picture is clearer I figure it'll be easier for me at least to
provide some text advice here... For starters though, the "Then, the"
for each option is superfluous - just go with "The"... Also, "...and are
curious if for instance should use VFIO..." doesn't read well or convey
(at least to me) what to expect.
John
=item B<inject-nmi> I<domain>
Inject NMI to the guest.
1:09 p.m.
New subject: [libvirt] [PATCH for 1.2.7 3/8] virsh: expose virConnectGetDomainCapabilities
On 06/30/2014 11:31 AM, Michal Privoznik wrote:
The API is exposed under 'domcapabilities' command.
Currently, with
the variety of drivers that libvirt supports, none of the command
arguments is obligatory, but all are optional instead.
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
---
tools/virsh-host.c | 84 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
tools/virsh.pod | 16 +++++++++++
2 files changed, 100 insertions(+)
diff --git a/tools/virsh-host.c b/tools/virsh-host.c
index 734f1a8..a1d8465 100644
--- a/tools/virsh-host.c
+++ b/tools/virsh-host.c
@@ -69,6 +69,84 @@ cmdCapabilities(vshControl *ctl, const vshCmd *cmd ATTRIBUTE_UNUSED)
}
/*
+ * "domcapabilities" command
+ */
+static const vshCmdInfo info_domcapabilities[] = {
+ {.name = "help",
+ .data = N_("domain capabilities")
+ },
+ {.name = "desc",
+ .data = N_("Returns capabilities of emulator with respect to host and
libvirt.")
+ },
+ {.name = NULL}
+};
+
+static const vshCmdOptDef opts_domcapabilities[] = {
+ {.name = "virttype",
+ .type = VSH_OT_STRING,
+ .help = N_("virtualization type (/domain/@type)"),
+ },
+ {.name = "emulatorbin",
+ .type = VSH_OT_STRING,
+ .help = N_("path to emulator binary (/domain/devices/emulator)"),
+ },
+ {.name = "arch",
+ .type = VSH_OT_STRING,
+ .help = N_("domain architecture (/domain/os/type/@arch)"),
+ },
+ {.name = "machine",
+ .type = VSH_OT_STRING,
+ .help = N_("machine type (/domain/os/type/@machine)"),
+ },
+ {.name = NULL}
+};
+
+static bool
+cmdDomCapabilities(vshControl *ctl, const vshCmd *cmd)
+{
+ bool ret = false;
+ char *caps;
+ const char *virttype = NULL;
+ const char *emulatorbin = NULL;
+ const char *arch = NULL;
+ const char *machine = NULL;
+ const unsigned int flags = 0; /* No flags so far */
+
+ if (vshCommandOptString(cmd, "virttype", &virttype) < 0) {
+ vshError(ctl, "%s", _("ble"));
+ goto cleanup;
+ }
+
+ if (vshCommandOptString(cmd, "emulatorbin", &emulatorbin) < 0) {
+ vshError(ctl, "%s", _("ble"));
+ goto cleanup;
+ }
+
+ if (vshCommandOptString(cmd, "arch", &arch) < 0) {
+ vshError(ctl, "%s", _("ble"));
+ goto cleanup;
+ }
+
+ if (vshCommandOptString(cmd, "machine", &machine) < 0) {
+ vshError(ctl, "%s", _("ble"));
+ goto cleanup;
+ }
+
+ caps = virConnectGetDomainCapabilities(ctl->conn, emulatorbin,
+ arch, machine, virttype, flags);
+ if (!caps) {
+ vshError(ctl, "%s", _("failed to get emulator
capabilities"));
+ goto cleanup;
+ }
+
+ vshPrint(ctl, "%s\n", caps);
+ ret = true;
+ cleanup:
+ VIR_FREE(caps);
+ return ret;
+}
+
+/*
* "freecell" command
*/
static const vshCmdInfo info_freecell[] = {
@@ -1131,6 +1209,12 @@ const vshCmdDef hostAndHypervisorCmds[] = {
.info = info_cpu_models,
.flags = 0
},
+ {.name = "domcapabilities",
+ .handler = cmdDomCapabilities,
+ .opts = opts_domcapabilities,
+ .info = info_domcapabilities,
+ .flags = 0
+ },
{.name = "freecell",
.handler = cmdFreecell,
.opts = opts_freecell,
diff --git a/tools/virsh.pod b/tools/virsh.pod
index b248c9a..b37a2be 100644
--- a/tools/virsh.pod
+++ b/tools/virsh.pod
@@ -350,6 +350,22 @@ description see:
L<http://libvirt.org/formatcaps.html>
The XML also show the NUMA topology information if available.
Oy - ...the XML also show*s* the NUMA...
+=item B<domcapabilities> [I<virttype>] [I<emulatorbin>]
+[I<arch>] [I<machine>]
+
+Print an XML document describing the capabilities of the
+hypervisor we are currently connected to. This may be useful if
+you intend to create a new domain and are curious if for instance
+should use VFIO or legacy KVM device passthrough. The I<virttype>
+specifies the virtualization used (the domain XML counterpart is
+the 'type' attribute of the <domain/> top level element). Then,
+the I<emulatorbin> specifies the path to the emulator (this is
+same as <emulator> element in the domain XML). Then, the I<arch>
+argument sets the domain architecture (exposed under
+/domain/os/type/@arch attribute). Then at last I<machine>
+overrides the default machine for the emulator (can be found in
+domain XML under /domain/os/type).
+
[OK so given everything thus far...]
Print an XML document describing the domain capabilities for the
hypervisor we are connected to using information either sourced from an
existing domain or taken from the B<virsh capabilities> output. This may
be useful if you intend to create a new domain and are curious if for
instance it could make use of VFIO by creating a domain for the
hypervisor with a specific emulator and architecture.
Each hypervisor will have different requirements regarding which options
are required and which are optional. A hypervisor can support providing
a default value for any of the options.
The I<virttype> option specifies the virtualization type used. The value
to be used is either from the 'type' attribute of the <domain/> top
level element from the domain XML or the 'type' attribute found within
each <guest/> element from the B<virsh capabilities> output. The
I<emulatorbin> option specifies the path to the emulator. The value to
be used is either the <emulator> element in the domain XML or the
B<virsh capabilities> output. The I<arch> option specifies the
architecture to be used for the domain. The value to be used is either
the "arch" attribute from the domain's XML <os/> element and
<type/>
subelement or the "name" attribute of an <arch/> element from the
B<virsh capabililites> output. The I<machine> specifies the machine type
for the emulator. The value to be used is either the "machine" attribute
from the domain's XML <os/> element and <type/> subelement or one from a
list of machines from the B<virsh capabilities> output for a specific
architecture and domain type.
For the qemu hypervisor, a I<virttype> of either 'qemu' or 'kvm'
must be
supplied along with either the I<emulatorbin> or I<arch> in order to
generate output for the default I<machine>. Supplying a I<machine>
value will generate output for the specific machine.
[Hope I got this right...]
=item B<inject-nmi> I<domain>
Inject NMI to the guest.
10:31 a.m.
New subject: [libvirt] [PATCH for 1.2.7 4/8] tests: Move qemu caps XML parsing into shared unit
Later on, we the qemu capabilities XML parsing code may come handy so
instead of duplicating the code make the already existing one shared.
By the same time, make the function accept file name instead of XML
document stored already in memory.
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
---
tests/qemucapabilitiestest.c | 57 +++-----------------------------------------
tests/testutilsqemu.c | 49 +++++++++++++++++++++++++++++++++++++
tests/testutilsqemu.h | 3 +++
3 files changed, 55 insertions(+), 54 deletions(-)
diff --git a/tests/qemucapabilitiestest.c b/tests/qemucapabilitiestest.c
index a291460..4e5f9e5 100644
--- a/tests/qemucapabilitiestest.c
+++ b/tests/qemucapabilitiestest.c
@@ -85,55 +85,6 @@ testQemuFeedMonitor(char *replies,
return NULL;
}
-static virQEMUCapsPtr
-testQemuGetCaps(char *caps)
-{
- virQEMUCapsPtr qemuCaps = NULL;
- xmlDocPtr xml;
- xmlXPathContextPtr ctxt = NULL;
- ssize_t i, n;
- xmlNodePtr *nodes = NULL;
-
- if (!(xml = virXMLParseStringCtxt(caps, "(test caps)", &ctxt)))
- goto error;
-
- if ((n = virXPathNodeSet("/qemuCaps/flag", ctxt, &nodes)) < 0) {
- fprintf(stderr, "failed to parse qemu capabilities flags");
- goto error;
- }
-
- if (n > 0) {
- if (!(qemuCaps = virQEMUCapsNew()))
- goto error;
-
- for (i = 0; i < n; i++) {
- char *str = virXMLPropString(nodes[i], "name");
- if (str) {
- int flag = virQEMUCapsTypeFromString(str);
- if (flag < 0) {
- fprintf(stderr, "Unknown qemu capabilities flag %s", str);
- VIR_FREE(str);
- goto error;
- }
- VIR_FREE(str);
- virQEMUCapsSet(qemuCaps, flag);
- }
- }
- }
-
- VIR_FREE(nodes);
- xmlFreeDoc(xml);
- xmlXPathFreeContext(ctxt);
- return qemuCaps;
-
- error:
- VIR_FREE(nodes);
- virObjectUnref(qemuCaps);
- xmlFreeDoc(xml);
- xmlXPathFreeContext(ctxt);
- return NULL;
-}
-
static int
testQemuCapsCompare(virQEMUCapsPtr capsProvided,
virQEMUCapsPtr capsComputed)
@@ -166,7 +117,7 @@ testQemuCaps(const void *opaque)
int ret = -1;
const testQemuData *data = opaque;
char *repliesFile = NULL, *capsFile = NULL;
- char *replies = NULL, *caps = NULL;
+ char *replies = NULL;
qemuMonitorTestPtr mon = NULL;
virQEMUCapsPtr capsProvided = NULL, capsComputed = NULL;
@@ -176,14 +127,13 @@ testQemuCaps(const void *opaque)
abs_srcdir, data->base) < 0)
goto cleanup;
- if (virtTestLoadFile(repliesFile, &replies) < 0 ||
- virtTestLoadFile(capsFile, &caps) < 0)
+ if (virtTestLoadFile(repliesFile, &replies) < 0)
goto cleanup;
if (!(mon = testQemuFeedMonitor(replies, data->xmlopt)))
goto cleanup;
- if (!(capsProvided = testQemuGetCaps(caps)))
+ if (!(capsProvided = qemuTestParseCapabilities(capsFile)))
goto cleanup;
if (!(capsComputed = virQEMUCapsNew()))
@@ -207,7 +157,6 @@ testQemuCaps(const void *opaque)
VIR_FREE(repliesFile);
VIR_FREE(capsFile);
VIR_FREE(replies);
- VIR_FREE(caps);
qemuMonitorTestFree(mon);
virObjectUnref(capsProvided);
virObjectUnref(capsComputed);
diff --git a/tests/testutilsqemu.c b/tests/testutilsqemu.c
index 7e24909..85f0356 100644
--- a/tests/testutilsqemu.c
+++ b/tests/testutilsqemu.c
@@ -373,4 +373,53 @@ testSCSIDeviceGetSgName(const char *sysfs_prefix ATTRIBUTE_UNUSED,
qemuBuildCommandLineCallbacks testCallbacks = {
.qemuGetSCSIDeviceSgName = testSCSIDeviceGetSgName,
};
+
+virQEMUCapsPtr
+qemuTestParseCapabilities(const char *capsFile)
+{
+ virQEMUCapsPtr qemuCaps = NULL;
+ xmlDocPtr xml;
+ xmlXPathContextPtr ctxt = NULL;
+ ssize_t i, n;
+ xmlNodePtr *nodes = NULL;
+
+ if (!(xml = virXMLParseFileCtxt(capsFile, &ctxt)))
+ goto error;
+
+ if ((n = virXPathNodeSet("/qemuCaps/flag", ctxt, &nodes)) < 0) {
+ fprintf(stderr, "failed to parse qemu capabilities flags");
+ goto error;
+ }
+
+ if (n > 0) {
+ if (!(qemuCaps = virQEMUCapsNew()))
+ goto error;
+
+ for (i = 0; i < n; i++) {
+ char *str = virXMLPropString(nodes[i], "name");
+ if (str) {
+ int flag = virQEMUCapsTypeFromString(str);
+ if (flag < 0) {
+ fprintf(stderr, "Unknown qemu capabilities flag %s", str);
+ VIR_FREE(str);
+ goto error;
+ }
+ VIR_FREE(str);
+ virQEMUCapsSet(qemuCaps, flag);
+ }
+ }
+ }
+
+ VIR_FREE(nodes);
+ xmlFreeDoc(xml);
+ xmlXPathFreeContext(ctxt);
+ return qemuCaps;
+
+ error:
+ VIR_FREE(nodes);
+ virObjectUnref(qemuCaps);
+ xmlFreeDoc(xml);
+ xmlXPathFreeContext(ctxt);
+ return NULL;
+}
#endif
diff --git a/tests/testutilsqemu.h b/tests/testutilsqemu.h
index f01b722..79ee143 100644
--- a/tests/testutilsqemu.h
+++ b/tests/testutilsqemu.h
@@ -3,8 +3,11 @@
# include "capabilities.h"
# include "domain_conf.h"
# include "qemu/qemu_command.h"
+# include "qemu/qemu_capabilities.h"
virCapsPtr testQemuCapsInit(void);
virDomainXMLOptionPtr testQemuXMLConfInit(void);
extern qemuBuildCommandLineCallbacks testCallbacks;
+
+virQEMUCapsPtr qemuTestParseCapabilities(const char *capsFile);
#endif
--
1.8.5.5
9:49 a.m.
New subject: [libvirt] [PATCH for 1.2.7 4/8] tests: Move qemu caps XML parsing into shared unit
On Mon, Jun 30, 2014 at 05:31:47PM +0200, Michal Privoznik wrote:
Later on, we the qemu capabilities XML parsing code may come handy
so
instead of duplicating the code make the already existing one shared.
By the same time, make the function accept file name instead of XML
document stored already in memory.
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
---
tests/qemucapabilitiestest.c | 57 +++-----------------------------------------
tests/testutilsqemu.c | 49 +++++++++++++++++++++++++++++++++++++
tests/testutilsqemu.h | 3 +++
3 files changed, 55 insertions(+), 54 deletions(-)
ACK
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 :|
10:31 a.m.
New subject: [libvirt] [PATCH for 1.2.7 5/8] qemu_capabilities: Introduce virQEMUCapsCacheLookupByArch
The API may come handy if somebody has an architecture and wants to
look through available qemus if the architecture is supported or not.
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
---
src/qemu/qemu_capabilities.c | 33 +++++++++++++++++++++++++++++++++
src/qemu/qemu_capabilities.h | 2 ++
2 files changed, 35 insertions(+)
diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
index 8e0a550..b357255 100644
--- a/src/qemu/qemu_capabilities.c
+++ b/src/qemu/qemu_capabilities.c
@@ -299,6 +299,10 @@ struct _virQEMUCapsCache {
gid_t runGid;
};
+struct virQEMUCapsSearchData {
+ virArch arch;
+};
+
static virClassPtr virQEMUCapsClass;
static void virQEMUCapsDispose(void *obj);
@@ -3465,6 +3469,35 @@ virQEMUCapsCacheLookupCopy(virQEMUCapsCachePtr cache, const char
*binary)
}
+static int
+virQEMUCapsCompareArch(const void *payload,
+ const void *name ATTRIBUTE_UNUSED,
+ const void *opaque)
+{
+ struct virQEMUCapsSearchData *data = (struct virQEMUCapsSearchData *) opaque;
+ const virQEMUCaps *qemuCaps = payload;
+
+ return qemuCaps->arch == data->arch;
+}
+
+
+virQEMUCapsPtr
+virQEMUCapsCacheLookupByArch(virQEMUCapsCachePtr cache,
+ virArch arch)
+{
+ virQEMUCapsPtr ret = NULL;
+ struct virQEMUCapsSearchData data = { .arch = arch };
+
+ virMutexLock(&cache->lock);
+ ret = virHashSearch(cache->binaries, virQEMUCapsCompareArch, &data);
+ VIR_DEBUG("Returning caps %p for arch %s", ret, virArchToString(arch));
+ virObjectRef(ret);
+ virMutexUnlock(&cache->lock);
+
+ return ret;
+}
+
+
void
virQEMUCapsCacheFree(virQEMUCapsCachePtr cache)
{
diff --git a/src/qemu/qemu_capabilities.h b/src/qemu/qemu_capabilities.h
index 53ebe90..1eb92b5 100644
--- a/src/qemu/qemu_capabilities.h
+++ b/src/qemu/qemu_capabilities.h
@@ -274,6 +274,8 @@ virQEMUCapsPtr virQEMUCapsCacheLookup(virQEMUCapsCachePtr cache,
const char *binary);
virQEMUCapsPtr virQEMUCapsCacheLookupCopy(virQEMUCapsCachePtr cache,
const char *binary);
+virQEMUCapsPtr virQEMUCapsCacheLookupByArch(virQEMUCapsCachePtr cache,
+ virArch arch);
void virQEMUCapsCacheFree(virQEMUCapsCachePtr cache);
virCapsPtr virQEMUCapsInit(virQEMUCapsCachePtr cache);
--
1.8.5.5
9:50 a.m.
New subject: [libvirt] [PATCH for 1.2.7 5/8] qemu_capabilities: Introduce virQEMUCapsCacheLookupByArch
On Mon, Jun 30, 2014 at 05:31:48PM +0200, Michal Privoznik wrote:
The API may come handy if somebody has an architecture and wants to
look through available qemus if the architecture is supported or not.
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
---
src/qemu/qemu_capabilities.c | 33 +++++++++++++++++++++++++++++++++
src/qemu/qemu_capabilities.h | 2 ++
2 files changed, 35 insertions(+)
ACK
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 :|
10:31 a.m.
New subject: [libvirt] [PATCH for 1.2.7 6/8] qemu_capabilities: Introduce virQEMUCapsIsMachineSupported
This internal API is meant to answer the question 'Is this machine
type supported by given qemu?'.
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
---
src/qemu/qemu_capabilities.c | 14 ++++++++++++++
src/qemu/qemu_capabilities.h | 3 +++
2 files changed, 17 insertions(+)
diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
index b357255..46e469c 100644
--- a/src/qemu/qemu_capabilities.c
+++ b/src/qemu/qemu_capabilities.c
@@ -3542,3 +3542,17 @@ virQEMUCapsSupportsChardev(virDomainDefPtr def,
(chr->deviceType == VIR_DOMAIN_CHR_DEVICE_TYPE_CONSOLE &&
chr->targetType == VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_VIRTIO));
}
+
+
+bool
+virQEMUCapsIsMachineSupported(virQEMUCapsPtr qemuCaps,
+ const char *canonical_machine)
+{
+ size_t i;
+
+ for (i = 0; i < qemuCaps->nmachineTypes; i++) {
+ if (STREQ(canonical_machine, qemuCaps->machineTypes[i]))
+ return true;
+ }
+ return false;
+}
diff --git a/src/qemu/qemu_capabilities.h b/src/qemu/qemu_capabilities.h
index 1eb92b5..4857dfd 100644
--- a/src/qemu/qemu_capabilities.h
+++ b/src/qemu/qemu_capabilities.h
@@ -302,6 +302,9 @@ bool virQEMUCapsSupportsChardev(virDomainDefPtr def,
virQEMUCapsPtr qemuCaps,
virDomainChrDefPtr chr);
+bool virQEMUCapsIsMachineSupported(virQEMUCapsPtr qemuCaps,
+ const char *canonical_machine);
+
int virQEMUCapsInitGuestFromBinary(virCapsPtr caps,
const char *binary,
virQEMUCapsPtr qemubinCaps,
--
1.8.5.5
9:51 a.m.
New subject: [libvirt] [PATCH for 1.2.7 6/8] qemu_capabilities: Introduce virQEMUCapsIsMachineSupported
On Mon, Jun 30, 2014 at 05:31:49PM +0200, Michal Privoznik wrote:
This internal API is meant to answer the question 'Is this
machine
type supported by given qemu?'.
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
---
src/qemu/qemu_capabilities.c | 14 ++++++++++++++
src/qemu/qemu_capabilities.h | 3 +++
2 files changed, 17 insertions(+)
ACK
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 :|
10:31 a.m.
New subject: [libvirt] [PATCH for 1.2.7 7/8] qemu_capabilities: Introduce virQEMUCapsGetDefaultMachine
Sometimes it may be useful to get a default machine for given qemu
binary. Fortunately, the default machine is stored always on the first
position in the supported machines array.
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
---
src/qemu/qemu_capabilities.c | 9 +++++++++
src/qemu/qemu_capabilities.h | 2 ++
2 files changed, 11 insertions(+)
diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
index 46e469c..e4336e1 100644
--- a/src/qemu/qemu_capabilities.c
+++ b/src/qemu/qemu_capabilities.c
@@ -3556,3 +3556,12 @@ virQEMUCapsIsMachineSupported(virQEMUCapsPtr qemuCaps,
}
return false;
}
+
+
+const char *
+virQEMUCapsGetDefaultMachine(virQEMUCapsPtr qemuCaps)
+{
+ if (!qemuCaps->nmachineTypes)
+ return NULL;
+ return qemuCaps->machineTypes[0];
+}
diff --git a/src/qemu/qemu_capabilities.h b/src/qemu/qemu_capabilities.h
index 4857dfd..d0a1092 100644
--- a/src/qemu/qemu_capabilities.h
+++ b/src/qemu/qemu_capabilities.h
@@ -305,6 +305,8 @@ bool virQEMUCapsSupportsChardev(virDomainDefPtr def,
bool virQEMUCapsIsMachineSupported(virQEMUCapsPtr qemuCaps,
const char *canonical_machine);
+const char * virQEMUCapsGetDefaultMachine(virQEMUCapsPtr qemuCaps);
+
int virQEMUCapsInitGuestFromBinary(virCapsPtr caps,
const char *binary,
virQEMUCapsPtr qemubinCaps,
--
1.8.5.5
9:51 a.m.
New subject: [libvirt] [PATCH for 1.2.7 7/8] qemu_capabilities: Introduce virQEMUCapsGetDefaultMachine
On Mon, Jun 30, 2014 at 05:31:50PM +0200, Michal Privoznik wrote:
Sometimes it may be useful to get a default machine for given qemu
binary. Fortunately, the default machine is stored always on the first
position in the supported machines array.
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
---
src/qemu/qemu_capabilities.c | 9 +++++++++
src/qemu/qemu_capabilities.h | 2 ++
2 files changed, 11 insertions(+)
ACK
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 :|
10:31 a.m.
New subject: [libvirt] [PATCH for 1.2.7 8/8] qemu: Implement virConnectGetDomainCapabilities
So far only information on disks and host devices are exposed in the
capabilities XML. Well, at least something. Even a new test is
introduced. The qemu capabilities are stolen from already existing
qemucapabilities test. There's one tricky point though. Functions that
checks host's KVM and VFIO capabilities, are impossible to mock
currently. So in the test, we are setting the capabilities by hand.
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
---
src/libvirt_private.syms | 1 +
src/qemu/qemu_capabilities.c | 90 ++++++++++++++++++
src/qemu/qemu_capabilities.h | 4 +
src/qemu/qemu_driver.c | 101 +++++++++++++++++++++
tests/Makefile.am | 5 +
.../domaincaps-qemu_1.6.50-1.xml | 44 +++++++++
tests/domaincapstest.c | 45 +++++++++
7 files changed, 290 insertions(+)
create mode 100644 tests/domaincapsschemadata/domaincaps-qemu_1.6.50-1.xml
diff --git a/src/libvirt_private.syms b/src/libvirt_private.syms
index 40585bd..a1dc8ae 100644
--- a/src/libvirt_private.syms
+++ b/src/libvirt_private.syms
@@ -439,6 +439,7 @@ virDomainVideoTypeFromString;
virDomainVideoTypeToString;
virDomainVirtioEventIdxTypeFromString;
virDomainVirtioEventIdxTypeToString;
+virDomainVirtTypeFromString;
virDomainVirtTypeToString;
virDomainWatchdogActionTypeFromString;
virDomainWatchdogActionTypeToString;
diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
index e4336e1..9fc58ff 100644
--- a/src/qemu/qemu_capabilities.c
+++ b/src/qemu/qemu_capabilities.c
@@ -39,6 +39,7 @@
#include "virnodesuspend.h"
#include "qemu_monitor.h"
#include "virstring.h"
+#include "qemu_hostdev.h"
#include <fcntl.h>
#include <sys/stat.h>
@@ -3565,3 +3566,92 @@ virQEMUCapsGetDefaultMachine(virQEMUCapsPtr qemuCaps)
return NULL;
return qemuCaps->machineTypes[0];
}
+
+
+static void
+virQEMUCapsFillDomainDeviceDiskCaps(virQEMUCapsPtr qemuCaps,
+ virDomainCapsDeviceDiskPtr disk)
+{
+ disk->device.supported = true;
+ /* QEMU supports all of these */
+ VIR_DOMAIN_CAPS_ENUM_SET(disk->diskDevice,
+ VIR_DOMAIN_DISK_DEVICE_DISK,
+ VIR_DOMAIN_DISK_DEVICE_CDROM,
+ VIR_DOMAIN_DISK_DEVICE_FLOPPY);
+
+ if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_VIRTIO_BLK_SG_IO))
+ VIR_DOMAIN_CAPS_ENUM_SET(disk->diskDevice, VIR_DOMAIN_DISK_DEVICE_LUN);
+
+ VIR_DOMAIN_CAPS_ENUM_SET(disk->bus,
+ VIR_DOMAIN_DISK_BUS_IDE,
+ VIR_DOMAIN_DISK_BUS_FDC,
+ VIR_DOMAIN_DISK_BUS_SCSI,
+ VIR_DOMAIN_DISK_BUS_VIRTIO,
+ VIR_DOMAIN_DISK_BUS_SD);
+
+ if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE_USB_STORAGE))
+ VIR_DOMAIN_CAPS_ENUM_SET(disk->bus, VIR_DOMAIN_DISK_BUS_USB);
+}
+
+
+static void
+virQEMUCapsFillDomainDeviceHostdevCaps(virQEMUCapsPtr qemuCaps,
+ virDomainCapsDeviceHostdevPtr hostdev)
+{
+ bool supportsPassthroughKVM = qemuHostdevHostSupportsPassthroughLegacy();
+ bool supportsPassthroughVFIO = qemuHostdevHostSupportsPassthroughVFIO();
+
+ hostdev->device.supported = true;
+ /* VIR_DOMAIN_HOSTDEV_MODE_CAPABILITIES is for containers only */
+ VIR_DOMAIN_CAPS_ENUM_SET(hostdev->subsysType,
+ VIR_DOMAIN_HOSTDEV_MODE_SUBSYS);
+
+ VIR_DOMAIN_CAPS_ENUM_SET(hostdev->startupPolicy,
+ VIR_DOMAIN_STARTUP_POLICY_DEFAULT,
+ VIR_DOMAIN_STARTUP_POLICY_MANDATORY,
+ VIR_DOMAIN_STARTUP_POLICY_REQUISITE,
+ VIR_DOMAIN_STARTUP_POLICY_OPTIONAL);
+
+ VIR_DOMAIN_CAPS_ENUM_SET(hostdev->subsysType,
+ VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_USB,
+ VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_PCI);
+ if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_DRIVE) &&
+ virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE) &&
+ virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE_SCSI_GENERIC))
+ VIR_DOMAIN_CAPS_ENUM_SET(hostdev->subsysType,
+ VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_SCSI);
+
+ /* No virDomainHostdevCapsType for QEMU */
+ virDomainCapsEnumClear(&hostdev->capsType);
+
+ virDomainCapsEnumClear(&hostdev->pciBackend);
+ if (supportsPassthroughVFIO &&
+ virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE_VFIO_PCI)) {
+ VIR_DOMAIN_CAPS_ENUM_SET(hostdev->pciBackend,
+ VIR_DOMAIN_HOSTDEV_PCI_BACKEND_DEFAULT,
+ VIR_DOMAIN_HOSTDEV_PCI_BACKEND_VFIO);
+ }
+
+ if (supportsPassthroughKVM &&
+ (virQEMUCapsGet(qemuCaps, QEMU_CAPS_PCIDEVICE) ||
+ virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE))) {
+ VIR_DOMAIN_CAPS_ENUM_SET(hostdev->pciBackend,
+ VIR_DOMAIN_HOSTDEV_PCI_BACKEND_DEFAULT,
+ VIR_DOMAIN_HOSTDEV_PCI_BACKEND_KVM);
+ }
+}
+
+
+void
+virQEMUCapsFillDomainCaps(virDomainCapsPtr domCaps,
+ virQEMUCapsPtr qemuCaps)
+{
+ virDomainCapsDeviceDiskPtr disk = &domCaps->disk;
+ virDomainCapsDeviceHostdevPtr hostdev = &domCaps->hostdev;
+ int maxvcpus = virQEMUCapsGetMachineMaxCpus(qemuCaps, domCaps->machine);
+
+ domCaps->maxvcpus = maxvcpus;
+
+ virQEMUCapsFillDomainDeviceDiskCaps(qemuCaps, disk);
+ virQEMUCapsFillDomainDeviceHostdevCaps(qemuCaps, hostdev);
+}
diff --git a/src/qemu/qemu_capabilities.h b/src/qemu/qemu_capabilities.h
index d0a1092..17be405 100644
--- a/src/qemu/qemu_capabilities.h
+++ b/src/qemu/qemu_capabilities.h
@@ -28,6 +28,7 @@
# include "capabilities.h"
# include "vircommand.h"
# include "qemu_monitor.h"
+# include "domain_capabilities.h"
/* Internal flags to keep track of qemu command line capabilities */
typedef enum {
@@ -314,4 +315,7 @@ int virQEMUCapsInitGuestFromBinary(virCapsPtr caps,
virQEMUCapsPtr kvmbinCaps,
virArch guestarch);
+void virQEMUCapsFillDomainCaps(virDomainCapsPtr domCaps,
+ virQEMUCapsPtr qemuCaps);
+
#endif /* __QEMU_CAPABILITIES_H__*/
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index 775f6ab..f5d28d5 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -95,6 +95,7 @@
#include "viraccessapicheckqemu.h"
#include "storage/storage_driver.h"
#include "virhostdev.h"
+#include "domain_capabilities.h"
#define VIR_FROM_THIS VIR_FROM_QEMU
@@ -16903,6 +16904,105 @@ qemuNodeGetFreePages(virConnectPtr conn,
}
+static char *
+qemuConnectGetDomainCapabilities(virConnectPtr conn,
+ const char *emulatorbin,
+ const char *arch_str,
+ const char *machine,
+ const char *virttype_str,
+ unsigned int flags)
+{
+ char *ret = NULL;
+ virQEMUDriverPtr driver = conn->privateData;
+ virQEMUCapsPtr qemuCaps = NULL;
+ int virttype; /* virDomainVirtType */
+ virDomainCapsPtr domCaps = NULL;
+ int arch = VIR_ARCH_NONE; /* virArch */
+
+ virCheckFlags(0, ret);
+ virCheckNonNullArgReturn(virttype_str, ret);
+
+ if (virConnectGetDomainCapabilitiesEnsureACL(conn) < 0)
+ return ret;
+
+ if ((virttype = virDomainVirtTypeFromString(virttype_str)) < 0) {
+ virReportError(VIR_ERR_INVALID_ARG,
+ _("unknown virttype: %s"),
+ virttype_str);
+ goto cleanup;
+ }
+
+ if (arch_str && (arch = virArchFromString(arch_str)) == VIR_ARCH_NONE) {
+ virReportError(VIR_ERR_INVALID_ARG,
+ _("unknown architecture: %s"),
+ arch_str);
+ goto cleanup;
+ }
+
+ if (emulatorbin) {
+ virArch arch_from_caps;
+
+ if (!(qemuCaps = virQEMUCapsCacheLookup(driver->qemuCapsCache,
+ emulatorbin)))
+ goto cleanup;
+
+ arch_from_caps = virQEMUCapsGetArch(qemuCaps);
+
+ if (arch == VIR_ARCH_NONE)
+ arch = arch_from_caps;
+
+ if (arch_from_caps != arch) {
+ virReportError(VIR_ERR_INVALID_ARG,
+ _("architecture from emulator '%s' doesn't
"
+ "match given architecture '%s'"),
+ virArchToString(arch_from_caps),
+ virArchToString(arch));
+ goto cleanup;
+ }
+ } else if (arch_str) {
+ if (!(qemuCaps = virQEMUCapsCacheLookupByArch(driver->qemuCapsCache,
+ arch)))
+ goto cleanup;
+
+ if (!emulatorbin)
+ emulatorbin = virQEMUCapsGetBinary(qemuCaps);
+ /* Deliberately not checking if provided @emulatorbin matches @arch,
+ * since if @emulatorbin was specified the match has been checked a few
+ * lines above. */
+ } else {
+ virReportError(VIR_ERR_INVALID_ARG, "%s",
+ _("at least one of emulatorbin or "
+ "architecture fields must be present"));
+ goto cleanup;
+ }
+
+ if (machine) {
+ /* Turn @machine into canonical name */
+ machine = virQEMUCapsGetCanonicalMachine(qemuCaps, machine);
+
+ if (!virQEMUCapsIsMachineSupported(qemuCaps, machine)) {
+ virReportError(VIR_ERR_INVALID_ARG,
+ _("the machine '%s' is not supported by emulator
'%s'"),
+ machine, emulatorbin);
+ goto cleanup;
+ }
+ } else {
+ machine = virQEMUCapsGetDefaultMachine(qemuCaps);
+ }
+
+ if (!(domCaps = virDomainCapsNew(emulatorbin, machine, arch, virttype)))
+ goto cleanup;
+
+ virQEMUCapsFillDomainCaps(domCaps, qemuCaps);
+
+ ret = virDomainCapsFormat(domCaps);
+ cleanup:
+ virObjectUnref(domCaps);
+ virObjectUnref(qemuCaps);
+ return ret;
+}
+
+
static virDriver qemuDriver = {
.no = VIR_DRV_QEMU,
.name = QEMU_DRIVER_NAME,
@@ -17098,6 +17198,7 @@ static virDriver qemuDriver = {
.domainGetTime = qemuDomainGetTime, /* 1.2.5 */
.domainSetTime = qemuDomainSetTime, /* 1.2.5 */
.nodeGetFreePages = qemuNodeGetFreePages, /* 1.2.6 */
+ .connectGetDomainCapabilities = qemuConnectGetDomainCapabilities, /* 1.2.7 */
};
diff --git a/tests/Makefile.am b/tests/Makefile.am
index 97af0d9..a262c7b 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -835,6 +835,11 @@ domaincapstest_SOURCES = \
domaincapstest.c testutils.h testutils.c
domaincapstest_LDADD = $(LDADDS)
+if WITH_QEMU
+domaincapstest_SOURCES += testutilsqemu.c testutilsqemu.h
+domaincapstest_LDADD += $(qemu_LDADDS)
+endif WITH_QEMU
+
if WITH_LIBVIRTD
libvirtdconftest_SOURCES = \
libvirtdconftest.c testutils.h testutils.c \
diff --git a/tests/domaincapsschemadata/domaincaps-qemu_1.6.50-1.xml
b/tests/domaincapsschemadata/domaincaps-qemu_1.6.50-1.xml
new file mode 100644
index 0000000..562e2f4
--- /dev/null
+++ b/tests/domaincapsschemadata/domaincaps-qemu_1.6.50-1.xml
@@ -0,0 +1,44 @@
+<domainCapabilities>
+ <path>/usr/bin/qemu-system-x86_64</path>
+ <domain>kvm</domain>
+ <machine>pc-1.2</machine>
+ <arch>x86_64</arch>
+ <devices>
+ <disk supported='yes'>
+ <enum name='diskDevice'>
+ <value>disk</value>
+ <value>cdrom</value>
+ <value>floppy</value>
+ <value>lun</value>
+ </enum>
+ <enum name='bus'>
+ <value>ide</value>
+ <value>fdc</value>
+ <value>scsi</value>
+ <value>virtio</value>
+ <value>usb</value>
+ <value>sd</value>
+ </enum>
+ </disk>
+ <hostdev supported='yes'>
+ <enum name='mode'/>
+ <enum name='startupPolicy'>
+ <value>default</value>
+ <value>mandatory</value>
+ <value>requisite</value>
+ <value>optional</value>
+ </enum>
+ <enum name='subsysType'>
+ <value>usb</value>
+ <value>pci</value>
+ <value>scsi</value>
+ </enum>
+ <enum name='capsType'/>
+ <enum name='pciBackend'>
+ <value>default</value>
+ <value>kvm</value>
+ <value>vfio</value>
+ </enum>
+ </hostdev>
+ </devices>
+</domainCapabilities>
diff --git a/tests/domaincapstest.c b/tests/domaincapstest.c
index 6cdd086..78197e2 100644
--- a/tests/domaincapstest.c
+++ b/tests/domaincapstest.c
@@ -54,6 +54,30 @@ fillAll(virDomainCapsPtr domCaps,
SET_ALL_BITS(hostdev->pciBackend);
}
+
+#ifdef WITH_QEMU
+# include "testutilsqemu.h"
+static void
+fillQemuCaps(virDomainCapsPtr domCaps,
+ void *opaque)
+{
+ virQEMUCapsPtr qemuCaps = (virQEMUCapsPtr) opaque;
+
+ virQEMUCapsFillDomainCaps(domCaps, qemuCaps);
+
+ /* The function above tries to query host's KVM & VFIO capabilities by
+ * calling qemuHostdevHostSupportsPassthroughLegacy() and
+ * qemuHostdevHostSupportsPassthroughVFIO() which, however, can't be
+ * successfully mocked as they are not exposed as internal APIs. Therefore,
+ * instead of mocking set the expected values here by hand. */
+ VIR_DOMAIN_CAPS_ENUM_SET(domCaps->hostdev.pciBackend,
+ VIR_DOMAIN_HOSTDEV_PCI_BACKEND_DEFAULT,
+ VIR_DOMAIN_HOSTDEV_PCI_BACKEND_KVM,
+ VIR_DOMAIN_HOSTDEV_PCI_BACKEND_VFIO);
+}
+#endif /* WITH_QEMU */
+
+
static virDomainCapsPtr
buildVirDomainCaps(const char *emulatorbin,
const char *machine,
@@ -143,6 +167,27 @@ mymain(void)
DO_TEST("full", "/bin/emulatorbin", "my-machine-type",
VIR_ARCH_X86_64, VIR_DOMAIN_VIRT_KVM, .fillFunc = fillAll);
+#ifdef WITH_QEMU
+
+# define DO_TEST_QEMU(Filename, QemuCapsFile, Emulatorbin, Machine, Arch, Type, ...)
\
+ do {
\
+ const char *capsPath = abs_srcdir "/qemucapabilitiesdata/" QemuCapsFile
".caps"; \
+ virQEMUCapsPtr qemuCaps = qemuTestParseCapabilities(capsPath);
\
+ struct test_virDomainCapsFormatData data = {.filename = Filename,
\
+ .emulatorbin = Emulatorbin, .machine = Machine, .arch = Arch,
\
+ .type = Type, .fillFunc = fillQemuCaps, .opaque = qemuCaps};
\
+ if (!qemuCaps) {
\
+ fprintf(stderr, "Unable to build qemu caps from %s\n", capsPath);
\
+ ret = -1;
\
+ } else if (virtTestRun(Filename, test_virDomainCapsFormat, &data) < 0)
\
+ ret = -1;
\
+ } while (0)
+
+ DO_TEST_QEMU("qemu_1.6.50-1", "caps_1.6.50-1",
"/usr/bin/qemu-system-x86_64",
+ "pc-1.2", VIR_ARCH_X86_64, VIR_DOMAIN_VIRT_KVM);
+
+#endif /* WITH_QEMU */
+
return ret;
}
--
1.8.5.5
9:56 a.m.
New subject: [libvirt] [PATCH for 1.2.7 8/8] qemu: Implement virConnectGetDomainCapabilities
On Mon, Jun 30, 2014 at 05:31:51PM +0200, Michal Privoznik wrote:
So far only information on disks and host devices are exposed in the
capabilities XML. Well, at least something. Even a new test is
introduced. The qemu capabilities are stolen from already existing
qemucapabilities test. There's one tricky point though. Functions that
checks host's KVM and VFIO capabilities, are impossible to mock
currently. So in the test, we are setting the capabilities by hand.
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
---
src/libvirt_private.syms | 1 +
src/qemu/qemu_capabilities.c | 90 ++++++++++++++++++
src/qemu/qemu_capabilities.h | 4 +
src/qemu/qemu_driver.c | 101 +++++++++++++++++++++
tests/Makefile.am | 5 +
.../domaincaps-qemu_1.6.50-1.xml | 44 +++++++++
tests/domaincapstest.c | 45 +++++++++
7 files changed, 290 insertions(+)
create mode 100644 tests/domaincapsschemadata/domaincaps-qemu_1.6.50-1.xml
+static void
+virQEMUCapsFillDomainDeviceDiskCaps(virQEMUCapsPtr qemuCaps,
+ virDomainCapsDeviceDiskPtr disk)
+{
+ disk->device.supported = true;
+ /* QEMU supports all of these */
+ VIR_DOMAIN_CAPS_ENUM_SET(disk->diskDevice,
+ VIR_DOMAIN_DISK_DEVICE_DISK,
+ VIR_DOMAIN_DISK_DEVICE_CDROM,
+ VIR_DOMAIN_DISK_DEVICE_FLOPPY);
+
+ if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_VIRTIO_BLK_SG_IO))
+ VIR_DOMAIN_CAPS_ENUM_SET(disk->diskDevice, VIR_DOMAIN_DISK_DEVICE_LUN);
+
+ VIR_DOMAIN_CAPS_ENUM_SET(disk->bus,
+ VIR_DOMAIN_DISK_BUS_IDE,
+ VIR_DOMAIN_DISK_BUS_FDC,
+ VIR_DOMAIN_DISK_BUS_SCSI,
+ VIR_DOMAIN_DISK_BUS_VIRTIO,
+ VIR_DOMAIN_DISK_BUS_SD);
I have a feeling that 'SD' is not supported in all QEMU's we claim to
work with, though perhaps we've never checked this before when
building the CLI args.
+
+ if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE_USB_STORAGE))
+ VIR_DOMAIN_CAPS_ENUM_SET(disk->bus, VIR_DOMAIN_DISK_BUS_USB);
+}
+
+
+ <hostdev supported='yes'>
+ <enum name='mode'/>
Hmm, so that's claiming we don't support any values for
the mode attribute, but we support subsys.
+ <enum name='startupPolicy'>
+ <value>default</value>
+ <value>mandatory</value>
+ <value>requisite</value>
+ <value>optional</value>
+ </enum>
+ <enum name='subsysType'>
+ <value>usb</value>
+ <value>pci</value>
+ <value>scsi</value>
+ </enum>
+ <enum name='capsType'/>
Yep, only LXC supports the caps mode.
+ <enum name='pciBackend'>
+ <value>default</value>
+ <value>kvm</value>
+ <value>vfio</value>
+ </enum>
+ </hostdev>
+ </devices>
+</domainCapabilities>
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 :|
4:55 a.m.
New subject: [libvirt] [PATCH for 1.2.7 8/8] qemu: Implement virConnectGetDomainCapabilities
On 02.07.2014 16:56, Daniel P. Berrange wrote:
On Mon, Jun 30, 2014 at 05:31:51PM +0200, Michal Privoznik wrote:
> So far only information on disks and host devices are exposed in the
> capabilities XML. Well, at least something. Even a new test is
> introduced. The qemu capabilities are stolen from already existing
> qemucapabilities test. There's one tricky point though. Functions that
> checks host's KVM and VFIO capabilities, are impossible to mock
> currently. So in the test, we are setting the capabilities by hand.
>
> Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
> ---
> src/libvirt_private.syms | 1 +
> src/qemu/qemu_capabilities.c | 90 ++++++++++++++++++
> src/qemu/qemu_capabilities.h | 4 +
> src/qemu/qemu_driver.c | 101 +++++++++++++++++++++
> tests/Makefile.am | 5 +
> .../domaincaps-qemu_1.6.50-1.xml | 44 +++++++++
> tests/domaincapstest.c | 45 +++++++++
> 7 files changed, 290 insertions(+)
> create mode 100644 tests/domaincapsschemadata/domaincaps-qemu_1.6.50-1.xml
>
> +static void
> +virQEMUCapsFillDomainDeviceDiskCaps(virQEMUCapsPtr qemuCaps,
> + virDomainCapsDeviceDiskPtr disk)
> +{
> + disk->device.supported = true;
> + /* QEMU supports all of these */
> + VIR_DOMAIN_CAPS_ENUM_SET(disk->diskDevice,
> + VIR_DOMAIN_DISK_DEVICE_DISK,
> + VIR_DOMAIN_DISK_DEVICE_CDROM,
> + VIR_DOMAIN_DISK_DEVICE_FLOPPY);
> +
> + if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_VIRTIO_BLK_SG_IO))
> + VIR_DOMAIN_CAPS_ENUM_SET(disk->diskDevice, VIR_DOMAIN_DISK_DEVICE_LUN);
> +
> + VIR_DOMAIN_CAPS_ENUM_SET(disk->bus,
> + VIR_DOMAIN_DISK_BUS_IDE,
> + VIR_DOMAIN_DISK_BUS_FDC,
> + VIR_DOMAIN_DISK_BUS_SCSI,
> + VIR_DOMAIN_DISK_BUS_VIRTIO,
> + VIR_DOMAIN_DISK_BUS_SD);
I have a feeling that 'SD' is not supported in all QEMU's we claim to
work with, though perhaps we've never checked this before when
building the CLI args.
Well, we don't. I haven't found any code that checks for 'SD' in qemu
driver. I can remove it until the time we have a resolution.
> +
> + if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE_USB_STORAGE))
> + VIR_DOMAIN_CAPS_ENUM_SET(disk->bus, VIR_DOMAIN_DISK_BUS_USB);
> +}
> +
> +
> + <hostdev supported='yes'>
> + <enum name='mode'/>
Hmm, so that's claiming we don't support any values for
the mode attribute, but we support subsys.
Ouch, yeah. The problem is, I was not setting the correct struct member.
Here's the fix:
index 9fc58ff..6ed85a9 100644
--- a/src/qemu/qemu_capabilities.c
+++ b/src/qemu/qemu_capabilities.c
@@ -3603,7 +3603,7 @@
virQEMUCapsFillDomainDeviceHostdevCaps(virQEMUCapsPtr qemuCaps,
hostdev->device.supported = true;
/* VIR_DOMAIN_HOSTDEV_MODE_CAPABILITIES is for containers only */
- VIR_DOMAIN_CAPS_ENUM_SET(hostdev->subsysType,
+ VIR_DOMAIN_CAPS_ENUM_SET(hostdev->mode,
VIR_DOMAIN_HOSTDEV_MODE_SUBSYS);
VIR_DOMAIN_CAPS_ENUM_SET(hostdev->startupPolicy,
diff --git a/tests/domaincapsschemadata/domaincaps-qemu_1.6.50-1.xml
b/tests/domaincapsschemadata/domaincaps-qemu_1.6.50-1.xml
index 562e2f4..b7d9c26 100644
--- a/tests/domaincapsschemadata/domaincaps-qemu_1.6.50-1.xml
+++ b/tests/domaincapsschemadata/domaincaps-qemu_1.6.50-1.xml
@@ -21,7 +21,9 @@
</enum>
</disk>
<hostdev supported='yes'>
- <enum name='mode'/>
+ <enum name='mode'>
+ <value>subsystem</value>
+ </enum>
<enum name='startupPolicy'>
<value>default</value>
<value>mandatory</value>
Michal
5 a.m.
New subject: [libvirt] [PATCH for 1.2.7 8/8] qemu: Implement virConnectGetDomainCapabilities
On Thu, Jul 03, 2014 at 11:55:44AM +0200, Michal Privoznik wrote:
On 02.07.2014 16:56, Daniel P. Berrange wrote:
>On Mon, Jun 30, 2014 at 05:31:51PM +0200, Michal Privoznik wrote:
>>So far only information on disks and host devices are exposed in the
>>capabilities XML. Well, at least something. Even a new test is
>>introduced. The qemu capabilities are stolen from already existing
>>qemucapabilities test. There's one tricky point though. Functions that
>>checks host's KVM and VFIO capabilities, are impossible to mock
>>currently. So in the test, we are setting the capabilities by hand.
>>
>>Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
>>---
>> src/libvirt_private.syms | 1 +
>> src/qemu/qemu_capabilities.c | 90 ++++++++++++++++++
>> src/qemu/qemu_capabilities.h | 4 +
>> src/qemu/qemu_driver.c | 101 +++++++++++++++++++++
>> tests/Makefile.am | 5 +
>> .../domaincaps-qemu_1.6.50-1.xml | 44 +++++++++
>> tests/domaincapstest.c | 45 +++++++++
>> 7 files changed, 290 insertions(+)
>> create mode 100644 tests/domaincapsschemadata/domaincaps-qemu_1.6.50-1.xml
>>
>
>
>>+static void
>>+virQEMUCapsFillDomainDeviceDiskCaps(virQEMUCapsPtr qemuCaps,
>>+ virDomainCapsDeviceDiskPtr disk)
>>+{
>>+ disk->device.supported = true;
>>+ /* QEMU supports all of these */
>>+ VIR_DOMAIN_CAPS_ENUM_SET(disk->diskDevice,
>>+ VIR_DOMAIN_DISK_DEVICE_DISK,
>>+ VIR_DOMAIN_DISK_DEVICE_CDROM,
>>+ VIR_DOMAIN_DISK_DEVICE_FLOPPY);
>>+
>>+ if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_VIRTIO_BLK_SG_IO))
>>+ VIR_DOMAIN_CAPS_ENUM_SET(disk->diskDevice,
VIR_DOMAIN_DISK_DEVICE_LUN);
>>+
>>+ VIR_DOMAIN_CAPS_ENUM_SET(disk->bus,
>>+ VIR_DOMAIN_DISK_BUS_IDE,
>>+ VIR_DOMAIN_DISK_BUS_FDC,
>>+ VIR_DOMAIN_DISK_BUS_SCSI,
>>+ VIR_DOMAIN_DISK_BUS_VIRTIO,
>>+ VIR_DOMAIN_DISK_BUS_SD);
>
>I have a feeling that 'SD' is not supported in all QEMU's we claim to
>work with, though perhaps we've never checked this before when
>building the CLI args.
Well, we don't. I haven't found any code that checks for 'SD' in qemu
driver. I can remove it until the time we have a resolution.
>
>>+
>>+ if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE_USB_STORAGE))
>>+ VIR_DOMAIN_CAPS_ENUM_SET(disk->bus, VIR_DOMAIN_DISK_BUS_USB);
>>+}
>>+
>>+
>
>>+ <hostdev supported='yes'>
>>+ <enum name='mode'/>
>
>Hmm, so that's claiming we don't support any values for
>the mode attribute, but we support subsys.
Ouch, yeah. The problem is, I was not setting the correct struct member.
Here's the fix:
index 9fc58ff..6ed85a9 100644
--- a/src/qemu/qemu_capabilities.c
+++ b/src/qemu/qemu_capabilities.c
@@ -3603,7 +3603,7 @@ virQEMUCapsFillDomainDeviceHostdevCaps(virQEMUCapsPtr
qemuCaps,
hostdev->device.supported = true;
/* VIR_DOMAIN_HOSTDEV_MODE_CAPABILITIES is for containers only */
- VIR_DOMAIN_CAPS_ENUM_SET(hostdev->subsysType,
+ VIR_DOMAIN_CAPS_ENUM_SET(hostdev->mode,
VIR_DOMAIN_HOSTDEV_MODE_SUBSYS);
VIR_DOMAIN_CAPS_ENUM_SET(hostdev->startupPolicy,
diff --git a/tests/domaincapsschemadata/domaincaps-qemu_1.6.50-1.xml
b/tests/domaincapsschemadata/domaincaps-qemu_1.6.50-1.xml
index 562e2f4..b7d9c26 100644
--- a/tests/domaincapsschemadata/domaincaps-qemu_1.6.50-1.xml
+++ b/tests/domaincapsschemadata/domaincaps-qemu_1.6.50-1.xml
@@ -21,7 +21,9 @@
</enum>
</disk>
<hostdev supported='yes'>
- <enum name='mode'/>
+ <enum name='mode'>
+ <value>subsystem</value>
+ </enum>
<enum name='startupPolicy'>
<value>default</value>
<value>mandatory</value>
ACK
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 :|
3831
days inactive
3834
days old
26 comments
3 participants
participants (3)
-
Daniel P. Berrange -
John Ferlan -
Michal Privoznik