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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
