On Wed, Nov 23, 2022 at 12:29:24PM +0100, Jiri Denemark wrote:
> I really don't think we should allow this, especially not
for something
> which is clearly intended to be used for production deployment. Our
> hypervisor CLI passthrough is there to allow for short term workarounds
> for bugs, or to experiment with a feature before it is mapped into
> libvirt in a supported manner.
>
> If there are aspects related to QEMU configuration thiat are not in
> libvirt yet, we need to address those gaps, not provide yet another
> way to bypass libvirt mapping.
Indeed, this was definitely meant as a short term workaround for stuff
we don't have support for yet, for testing or experimental purposes. The
supported approach is for implement the missing parts in libvirt (and
QEMU) as soon as possible. I don't see why would a properly documented
support for experiments with -cpu would be an issue.
If anyone thinks it's a good idea to use such stuff for anything even
remotely close to production then that's their call. We can't really
prevent that. Just as with any other <qemu:...> stuff we already have.
Having two copies of essentially the same information that must be kept
perfectly in sync has been the direct cause of multiple serious bugs for us
(some self-inflicted, probably, but certainly not all). I understand that "fix
libvirt every time there's a disparity" is appealing but unfortunately in
practice this just hasn't been the case.
We're struggling to see what value the libvirt layer is bringing us in this
area, as opposed to a single-source-of-truth approach.
regards
john