Bug 1107842 - RFE: expose much more qemu capabilities in domcapabilites output
Summary: RFE: expose much more qemu capabilities in domcapabilites output
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Virtualization Tools
Classification: Community
Component: libvirt
Version: unspecified
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Libvirt Maintainers
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks: TRACKER-bugs-affecting-libguestfs
TreeView+ depends on / blocked
 
Reported: 2014-06-10 18:38 UTC by Richard W.M. Jones
Modified: 2020-04-17 12:23 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-04-17 12:23:41 UTC


Attachments (Terms of Use)

Description Richard W.M. Jones 2014-06-10 18:38:59 UTC
Description of problem:

At the moment, libguestfs has to guess at qemu features, when
the libvirt backend is used (when the direct backend is used, it
can test qemu itself).

In particular:

 - <bios useserial=yes>  (ie. sgabios)

 - <cpu mode=host-passthrough>

 - Whether the hpet timer needs to be disabled (see also bug 1066145)

 - Whether guests need a <dtb/> element

 - If qemu supports virtio-scsi

Libvirt should export this knowledge upwards to clients.

This list only covers what libguestfs needs, but libvirt knows a
great deal about qemu, and probably much more should be exposed
in capabilities.

Version-Release number of selected component (if applicable):

libvirt from git

Additional info:

https://github.com/libguestfs/libguestfs/blob/master/src/launch-libvirt.c

Comment 1 Daniel Berrangé 2014-06-26 10:46:27 UTC
The following patch series lays the foundation of a new API for reporting this kind of information per QEMU (binary, arch, machine, virttype) quartet. It shows how we'll expose info about supported enum values for devices

  https://www.redhat.com/archives/libvir-list/2014-June/msg01340.html

The API / XML concept is extensible to cover the other types of info you mention here too.

Comment 2 Cole Robinson 2016-04-10 18:50:00 UTC
Yeah the place for this to live is domcapabilities... there's a ton of info virt-manager would like here as well, check virt-manager.git/virtinst/support.py for some examples

The only way this is going to work though is if its keyed into libvirt's dev process that domcapabilities is extended when a new feature is added, since if the capabilities extension lags when the feature was added by a substantial period of time (like all the bits listed above), apps can't reliably depend on the output to exhaustively report all qemu versions that support the feature. apps will need to do

if (libvirt-is-new-enough)
  check-dom-capabilities
else
  use-manual-version-checking

so this types of caps reporting is only useful for _existing_ apps if the caps are extended when the feature is added to libvirt

Comment 3 Daniel Berrangé 2020-04-17 12:23:41 UTC
Closing this old RFE. The domain capabilities XML info is being expanded incrementally as people have use cases for new info.


Note You need to log in before you can comment on or make changes to this bug.