Re: [Qemu-devel] change x86 default machine type to Q35?

[Daniel P. Berrange]

On Thu, Jul 06, 2017 at 11:30:43AM +0100, Stefan Hajnoczi wrote:
> On Wed, Jul 05, 2017 at 12:07:57PM +0100, Daniel P. Berrange wrote:
> > On Wed, Jul 05, 2017 at 10:14:23AM +0200, Thomas Huth wrote:
> > >  Hi,
> > > 
> > > On 05.07.2017 08:57, Chao Peng wrote:
> > > > 
> > > > Q35 has been in QEMU for quite a while. Compared to the current default
> > > > i440FX, Q35 is probably not that mature and not widely used, however in
> > > > some case, Q35 has advantages, for example, in supporting new features.
> > > > For instance, we have some features require PCI-e support which is only
> > > > available on Q35 and some others need it for EFI support. It is of
> > > > course not necessary to change it as the default but if more and more
> > > > features have dependencies on Q35 because of requiring much more modern
> > > > features then I think it may be worth to do so. In such case we can have
> > > > more people to use it and find problems we may know or not know.
> > > 
> > > Yes, IMHO at one point in time, we should switch the default machine
> > > type to q35. The i440FX is really quite old...
> > > 
> > > > There are certainly some drawbacks:
> > > > -        Compatibility: current code or script may need adjustment
> > > 
> > > That might be a real concern ... so I think a good point in time to
> > > switch to the q35 machine type would be when we switch to the next major
> > > version number of QEMU, i.e. when we switch to version 3.0. If the users
> > > see a new major version number, they might be more willing to accept
> > > such major changes (yeah, I know, we've discussed in the past that
> > > version numbers are just numbers ... but still, there is some kind of
> > > psychological aspect to this, too, I think)
> > 
> > Most users aren't even aware of version numbers of QEMU - they'll just
> > take whatever their distro has provided run it. The notion that their
> > latest distro version happened to pull in a "major" version instead of
> > previously pulling in a "minor" version is invisible to everyone,
> > except the minority of people who care about the low level details.
> 
> When user-visible changes break existing setups it's common for
> packagers to ship a new family of packages that includes the major
> version number (e.g. apache2, postgresql-9.6).
> 
> The last QEMU 2.x version would be considered stable and still available
> from package repos.  Only critical bug and security fixes could be
> released for another, say, 2 years.
> 
> This way users don't have to migrate to QEMU 3.x until they are ready.

Given the number of security vulnerabilities packagers have to deal with
for QEMU, maintaining multiple QEMU streams in parallel is a pretty
major undertaking. I can't say that would be appealing from a Fedora
maintainer POV - it'd likely just end up shipping only the newest version
to avoid that extra maint burden. I doubt enterprise distros would ship
both versions in parallel in this way [1].

Even if both versions are available, the people affected by the breakage
still need to figure out that the breakage they're seeing is caused by
the change in machine type, and that installing the old version will
fix it. This is still an unpleasant experiance IMHO. 

Regards,
Daniel

[1] RHEL does already ship 2 QEMU streams in parallel, but they are
    differentiated for other reasons, one being a feature limited
    version of the other, and not as frequently rebased.
-- 
|: 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 :|