I feel like I've addressed most of your points in my reply to Peter's message so I won't repeat the same arguments and will snip quite aggressively, but please let me know if I've missed anything. On Tue, 2018-10-02 at 17:38 +0200, Pavel Hrdina wrote: [...] > But in this case I thing that it's time > to move to Q35 as a default machine type, it's supported by majority of > recent OSes and it would be sensible default. > > If some application/user depends on a specific machine type they should > ask for it and most likely they are already doing it. Even if we agreed that q35 is a better default than i440fx these days, changing libvirt's default would be, in my opinion, merely papering over the real issue, which is: there shouldn't have been a default to begin with. Applications should either choose a specific machine type because they know it's the only one the fits their needs (as you suggest) or, if they don't have such specialized needs, ask libosinfo to figure one out based on information such as the OS that will ultimately run in the guest; the same is true for network interfaces, storage controllers, graphics adapters and the like. The idea that you can have a single "good" default is one that was perhaps true years ago, but it's certainly not true today, and holding on to it only causes pain for users and developers alike. > We have a lot of > attributes in our XML that are usually filled in by default and that > default already depends on QEMU version or features that QEMU offers. We're actually awfully inconsistent in this, since we base some of the choices on QEMU features and have hardcoded values for others; in some particularly neat cases, we might even end up applying *both* approaches :) -- Andrea Bolognani / Red Hat / Virtualization -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
