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