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

[Eduardo Habkost]

On Thu, Jun 14, 2018 at 09:09:48AM +0100, Daniel P. Berrangé wrote:
> On Wed, Jun 13, 2018 at 03:05:08PM -0300, Eduardo Habkost wrote:
> > Getting back to this discussion:
> > 
> > On Tue, Jun 05, 2018 at 09:43:00AM +0100, Daniel P. Berrangé wrote:
> > > On Tue, Jun 05, 2018 at 09:27:46AM +0200, Gerd Hoffmann wrote:
> > > >   Hi,
> > > > 
> > > > > >   Add to that shortcuts like -cdrom
> > > > > > stop working,
> > > > > 
> > > > > Maybe is fixable.
> > > > 
> > > > Already fixed for ages.
> > > > 
> > > > > I see marking Q35 as the default machine a first step.
> > > > 
> > > > Maybe the better option is to go the arm route:  Just don't define a
> > > > default, so users have to specify pc or q35.  That will make them notice
> > > > there is a world beside 'pc', and we also avoid breaking things
> > > > silently.
> > > 
> > > If QEMU removes the default, then libvirt will have to hardcode
> > > 'pc' as the default to maintain back compatibility, so I don't
> > > think that ends up as a net win
> > 
> > I believe there's consensus that applications blindly relying on
> > the default machine-type when creating a domain is a bad idea.
> > 
> > That said, can we deprecate this feature in libvirt, encourage
> > applications to always specify an explicit machine-type, thus
> > making it possible to deprecate the i440fx machine-types one day?
> 
> Well from libvirt's POV this scenario arrives if a mgmt app simply omits
> the relevant element/attribute from the XML config. Deprecating something
> implies that in future we'd drop support for it, but we're never going
> to make this mandatory in libvirt as that would be a regression in
> behaviour from libvirt's POV. So I don't think it is something we would
> deprecate.

Does libvirt really have an option, here?  I'm sure that sooner
or later somebody will distribute QEMU binaries without "pc".


> I'm happy to see an update to the XML docs to strongly recommend that
> apps always provide a machine type though. Many will likely already be
> doing so with aarch64 to get the "virt" machine type anyway, since the
> default libvirt picks is often not suitable.

Well, if you don't want to explicitly remove the default-is-pc
feature from libvirt, strongly recommending against it (and
letting people know that it may stop working in the future) might
be enough.

-- 
Eduardo