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

On Wed, 2019-01-16 at 14:19 +0000, Daniel P. Berrangé wrote: > 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: > > > 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. That will still result in guests disappearing at some point, which is not something that we're generally okay with. Why would it be any different this time around?

> > 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. If we're willing to leave some theoretical users of impractical network devices in the dust, then coming up with a reasonably small list for QEMU is not too difficult either... But see above :)