Re: [Qemu-devel] [libvirt] libvirt default machine-type guarantees? (was Re: [PATCH RFC] hw/pc: set q35 as the default x86 machine)

[Pavel Hrdina <phrdina@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 4049 bytes --]

On Tue, Jun 05, 2018 at 03:07:04PM +0100, Daniel P. Berrangé wrote:
> On Tue, Jun 05, 2018 at 11:03:46AM -0300, Eduardo Habkost wrote:
> > On Tue, Jun 05, 2018 at 03:44:39PM +0200, Pavel Hrdina wrote:
> > > On Tue, Jun 05, 2018 at 10:35:38AM -0300, Eduardo Habkost wrote:
> > > > On Tue, Jun 05, 2018 at 02:12:32PM +0100, Daniel P. Berrangé wrote:
> > > > > On Tue, Jun 05, 2018 at 10:06:46AM -0300, Eduardo Habkost wrote:
> > > > > > (CCing libvir-list)
> > > > > > 
> > > > > > 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
> > > > > > 
> > > > > > Is there an actual promise to never change the default
> > > > > > machine-type documented in the libvirt API, or is this just fear
> > > > > > of breaking existing code?
> > > > > 
> > > > > The risk of breaking things that currently work. Some of the things
> > > > > discussed here that risk breaking users if QEMU changes the default,
> > > > > have the same risk if libvirt changes the default.
> > > > > 
> > > > > eg old OS versions that only work with PC, or more commonly pre-existing
> > > > > cloud disk images that were built against PC can't be assumed to just
> > > > > work against q35, even if the OS in the image supports it.
> > > > > 
> > > > > If we want to get q35 broadly used for modern OS, then IMHO the best
> > > > > option is to record that metadata in libosinfo, as ew do for other
> > > > > virtual hardware preferences.  That doesn't fix the problem of disk
> > > > > images that might not transparently boot between pc/q35, but at least
> > > > > avoids breaking OS that don't support q35 at all.
> > > > 
> > > > This leads to a more general question: sometimes the defaults
> > > > chosen by libvirt are obsolete or broken, and we might want to
> > > > change them.
> > > > 
> > > > Is there a process for changing defaults in libvirt, or libvirt
> > > > is bound by past decisions forever?
> > > 
> > > If the default was always recorded in the domain XML it is safe to
> > > change it because it will not affect already existing domains or
> > > migration but if the default is not recorded in the domain XML there
> > > needs to be a lot of compatibility code.
> > 
> > That's the opposite of what Daniel said above, isn't it?  The
> > machine-type is always recorded in the domain XML, but it's still
> > considered unsafe to change.
> 
> Yes, I disagree with that Pavel has written here. The domain XML recording
> of settings is critical for preserving guest ABI for migration, etc, so
> obviously must be stable. Even if there is *no* domain XML yet, however,
> libvirt still aims to avoid changes in defaults that are liable to break
> an existing mgmt application creating guests in future.

Yes in general we try to avoid changing defaults and no it's possible to
do it if there is good reason <568887a32f9985b95d998dd0d675255ea985013f>.

So technically there is a way but usually it's not good idea.  I should
have noted in the first reply that machine type is huge change and that
my statement applies to smaller changes.

Pavel

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]