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