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

[Daniel P. Berrangé]

On Wed, Jan 16, 2019 at 03:46:12PM +0100, Andrea Bolognani wrote:
> 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?

No change we make is perfectly risk free. We would want to have
reasonable confidence that the initial enum is a good as we can
practically make it. The tainting check & log is a way to identify
if we made some mistakes - hopefully we won't have. If users do
report it though, we'll be able to fix it. If we get no reports
for a reasonable period of time (minimum 12 months), it is OK to
assume we've not broken anything that we believe has users. 

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

The QEMU list won't be small - it'll be large given all archs !

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