Re: [Qemu-devel] [PATCH RFC] hw/pc: set q35 as the default x86 machine

[Eduardo Habkost <ehabkost@redhat.com>]

On Mon, Jun 04, 2018 at 09:40:15PM +0300, Marcel Apfelbaum wrote:
> 
> 
> On 06/04/2018 07:56 PM, Daniel P. Berrangé wrote:
> > On Mon, Jun 04, 2018 at 07:48:51PM +0300, Michael S. Tsirkin wrote:
> > > On Mon, Jun 04, 2018 at 02:01:29PM +0100, Daniel P. Berrangé wrote:
> > > > On Mon, Jun 04, 2018 at 09:54:15AM -0300, Eduardo Habkost wrote:
> > > > > On Mon, Jun 04, 2018 at 04:38:22AM +0300, Michael S. Tsirkin wrote:
> > > > > > On Sun, Jun 03, 2018 at 12:27:49PM +0300, Marcel Apfelbaum wrote:
> > > > > > > Moving to QEMU 3.0 seems like a good opportunity for such a change.
> > > > > > > 
> > > > > > > I440FX is really old and does not support modern features like IOMMU.
> > > > > > > Q35's SATA emulation is faster than pc's IDE, native PCI express hotplug
> > > > > > > is cleaner than ACPI based one and so on...
> > > > > > > 
> > > > > > > Also the libvirt guys added very good support for the Q35 machine (thanks!).
> > > > > > > 
> > > > > > > Management software should always specify the machine type and for the
> > > > > > > current setups, adding '-machine pc' to the command line is not such a
> > > > > > > big deal.
> > > > > > > 
> > > > > > > In time the pc machine will fade out and we will probably stop adding
> > > > > > > new versions at some point.
> > > > > > > 
> > > > > > > Signed-off-by: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
> > > > > > For command line users, I think changing the default isn't nice.
> > > > > > 
> > > > > > Yes it's easy to add -machine pc but there's no documentation
> > > > > > that tells you to do so. Add to that shortcuts like -cdrom
> > > > > > stop working, hotplug needs extra bridges to work, and one
> > > > > > can see that while management tool users benefit from q35,
> > > > > > command line users will suffer.
> > > > > > 
> > > > > > Can't we add a tag for management without changing the command line
> > > > > > default? How about "management-default"? "recommended"? "latest"?
> > > > > We could add new aliases if they are useful for management
> > > > > software, but we would need a well-defined use case and set of
> > > > > requirements+expectations for the new alias.
> > > > I'm not convinced by the idea of adding a distinct default "for mgmt". All
> > > > the problems described wrt 'q35' vs 'pc' apply equally to management apps
> > > > as they do to humans. It just happens that one common mgmt layer (libvirt)
> > > > knows how to handle some of the complexity of q35. Other mgmt apps though
> > > > are just as likely to be hurt by the change as humans are. So effectively
> > > > the proposed "for mgmt" is actually  "for libvirt >= some version", which
> > > > feels like a layering violation to me.
> > > Is libvirt happy to just hard-code q35 for now then?
> > I'm pretty wary of doing that, as I feel 'pc' has broader OS compatibility
> > than 'q35', so we'd be likely to cause breakage for users.
> > 
> > IMHO, defaults are something better expressed in libosinfo, so if there's
> > guests where we think q35 is a better choice, we can record it there and
> > leave everything else on pc to avoid risk of breakage.
> 
> The only info we need to pass properly to management systems is:
> "Use q35 unless your guests are really old".

Or if your existing disk image contains drivers or other software
that work only with pc.  Or if it's going to trigger Windows
license reactivation on a disk image prepared using pc.

The stack can't change the default without breaking existing
guest images.  Whether it's a reasonable risk or it's
unacceptable depends on what are the intended audience and use
cases of a given management stack.  I don't think QEMU or libvirt
can make that decision for them.

That said, if something is going to break as soon as the default
in QEMU changes, that's a bug in the management stack.
Management stacks should stop assuming the default machine-type
in libvirt+QEMU is never going to change.

-- 
Eduardo