Add option to skip cpu feature and model verification in libvirt and rely on qemu 'enforce' option

[Daniel P. Berrangé]

On Wed, Nov 23, 2022 at 11:34:24AM +0000, John Levon wrote:
> 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.

Well libvirt's job is to insulate applications from the specific hypervisor
implementation details.

We support multiple hypervisors, and as such it is a goal that CPU feature
names at least are able to be made consistent across hypervisor drivers in
libvirt, but ideally CPU model names too that is more challenging to
achieve, depending on what config flexibility the hypervisor offers.
Still, directly exposing the hypervisor's specific names is an explicit
anti-goal.

Another factor is that QEMU configuration syntax changes over time, and
libvirt aims to transparently adapt to such changes, that includes
potential renames of flags/models.

There is always a chance of bugs when mapping from the hypervisor to
libvirt, but that's not a reason to abandon the core goals of libvirt
to isolate apps from the raw hypervisor impl details. Our focus needs
to be on reducing the chance of such bugs in libvirt and reducing any
time lag between features.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|