Bug 1107842

Summary:	RFE: expose much more qemu capabilities in domcapabilites output
Product:	[Community] Virtualization Tools	Reporter:	Richard W.M. Jones <rjones>
Component:	libvirt	Assignee:	Libvirt Maintainers <libvirt-maint>
Status:	CLOSED CURRENTRELEASE	QA Contact:
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	unspecified	CC:	berrange, crobinso
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2020-04-17 12:23:41 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	910269

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.