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

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.