[libvirt] [PATCH 0/6] RFC: qemu: virtio-{non-}transitional support

Daniel P. Berrangé berrange at redhat.com
Wed Jan 16 14:19:21 UTC 2019


On Wed, Jan 16, 2019 at 03:07:07PM +0100, Andrea Bolognani wrote:
> On Wed, 2019-01-16 at 11:13 +0000, Daniel P. Berrangé wrote:
> > On Wed, Jan 16, 2019 at 12:01:00PM +0100, Andrea Bolognani wrote:
> > > Based on what I can recall from my own, more recent, attempt at
> > > fixing the mess, the main blocker was that in order to keep
> > > accepting all existing configurations you'd basically have to
> > > still store the model as a string and only at a later time
> > > convert it to an enum.
> > 
> > The enum should cover all existing reasonably expected configs. Sure I
> > imagine we might miss a few, especially for obscure architectures or
> > hypervisors, but that would just be bugs to be fixed
> 
> Until we've fixed said bugs, guests using such models would just
> disappear though, wouldn't they? That doesn't sound acceptable.

We could do a multi-step conversion. First define an enum and report
all known enum values in the domain capabilities. Taint any guest
using a nic with doesn't match. A year or so later, then finally
enforce the enum usage.

> And defining even the incomplete enum would require someone to
> be familiar with all drivers in order to know which models are
> commonly used, or at all available.

It isn't as bad as it seems. VMWare has whitelisted names, Hyperv
doesn't report models at all, Xen is a small finite set. QEMU is
the only hard one given the huge set of system emulators.

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 :|




More information about the libvir-list mailing list