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
