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

[Stefan Hajnoczi]

On Thu, Jul 06, 2017 at 11:41:56AM +0100, Daniel P. Berrange wrote:
> 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. 

True, package naming doesn't provide an upgrade path.  That will still
be painful.

Stefan

signature.asc
Description: PGP signature