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