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@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.