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).
+
[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...]