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