Re: [libvirt] [PATCH] qemu: ensure default machine types don't change if QEMU changes
On Tue, 2018-08-07 at 16:01 +0100, Daniel P. Berrangé wrote:
On Tue, Aug 07, 2018 at 04:57:28PM +0200, Andrea Bolognani wrote:
> > > I wonder if we shouldn't just drop the default machine type handling
> > > altogether at this point, though.
> >
> > That's impossible as it violates the back compatibility guarantee
> > and will certainly break applications
>
> In abstract terms, given that the whole point of this exercise is
> shielding our users from changes in QEMU, why wouldn't we go the
> whole way and take QEMU defaults out of the picture entirely?
>
> I just can't picture a scenario where ignoring the QEMU defaults
> would actually cause issues, since we're basically moving the
> defaults into libvirt with this commit... Can you describe such
> a scenario?
Someone could build a QEMU with the "pc" machine type deleted entirely,
in which case libvirt won't find the default. The best we can do there
is fallback to QEMU's own default.
Yeah, that's basically my point: wouldn't it be better to error
out rather than silently pick up a different default which is not
controlled by libvirt?
Of course that would be slightly annoying for people building their
own QEMU binaries with machine types ripped out, but I can't
imagine that population being very large and they're certainly
capable enough to figure out a way around the error; most people
will get their QEMU and libvirt through downstream distributions,
and if the downstream changes the list of machines available in
QEMU they should patch libvirt to update the table anyway.
Ultimately, users and applications should make sure they include
an explicit machine type in the guest XML, so ideally in time this
code path will not be hit at all.
To avoid that problem we would have to maintain a sorted list of
every
single known machine type in every QEMU which gets a bit ridiculous.
Fully agreed :)
--
Andrea Bolognani / Red Hat / Virtualization