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

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.