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