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 <mpriv...@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.
>
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
