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).
- <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
Version-Release number of selected component (if applicable):
libvirt from git
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
The API / XML concept is extensible to cover the other types of info you mention here too.
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
so this types of caps reporting is only useful for _existing_ apps if the caps are extended when the feature is added to libvirt
Closing this old RFE. The domain capabilities XML info is being expanded incrementally as people have use cases for new info.