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

[Daniel P. Berrange]

On Wed, Jul 05, 2017 at 02:57:56PM +0800, Chao Peng wrote:
> Hi,
>  
> 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. There
> are certainly some drawbacks:
> -        Compatibility: current code or script may need adjustment
> -        Quality: we may suffer more bugs on Q35
> 
> Any thoughts?

Changing the default machine will certainly break a large number of
apps / scripts / users of QEMU because it completely changes the ABI
exposed to guest OS. It will also invalidate documentation about
QEMU usage across countless websites / source repos.

If you're lucky QEMU may immediately fail to start because a command
line argument refers to some property / device that exists by default
in PIIX, but not in Q35.

If you're unlucky QEMU will successfully start, but expose a different
ABI to the guest. This will cause Windows guests to trigger license
reactivation. It will cause QEMU to fail to load any previously saved
snapshots, and will fail to process incoming migration.

Then there is the fact that some guest OS may not work with the chipset
exposed by Q35.

While you can say people should just add '-M pc' that isn't a nice
user experiance, because it makes the assumption that people actually
understand what caused their breakage. When the incompatibilities
arise the error messages are unlikely to give any hint to users that
the problems are caused by the machine type change. So unless someone
is very familiar with debugging QEMU, they're not going to realize
that '-M pc' will fix their problem. Documentation assuming the old
defaults will live on forever, meaning users suffer from the change
in defaults for years, probably decades into the future.

All these problems can be avoided if the change in defaults in done by
higher level applications. For example, OpenStack/oVirt know what guest
OS is being deployed, so they can intelligently choose between either
Q35 or PIIX4, depending on which the guest is known to work with. These
apps will also have a persistent record of full guest config (via libvirt)
to the change in defaults won't risk breaking existing deployed guests,
or their snapshots & ensure migration continues to work.

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