[libvirt] [PATCH for 1.2.7 3/8] virsh: expose virConnectGetDomainCapabilities

[John Ferlan]

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