On Tue, Oct 02, 2018 at 18:26:12 +0200, Andrea Bolognani wrote: > On Tue, 2018-10-02 at 17:19 +0200, Peter Krempa wrote: > > Our documentation states in multiple places that fields not populated by > > the user are mostly hypervisor dependant what the default will become. > > > > In my opinion the machine type is similarly hypervisor dependant, and in > > this case the "hypervisor" for the libvirt-qemu infrastructure also > > involves libvirt's qemu driver. > > I don't necessarily disagree with you, but it should be noted that > attempts to change libvirt's own defaults have been rejected times > and times again on the basis that existing applications were, despite > that being a very bad idea, relying on them. I'm going to talk only about default values which are stored in domain XML once chosen here as the ones which do not make it into the XML are much more complicated and we can't easily change them... I think rejecting changes to libvirt's defaults in general is wrong. The defaults are not stable and have never been and we should stop pretending they are. When we select a default value for something we store it in the domain XML to protect us from future changes to the default value. Not to mention that defaults may depend on hypervisor version and we need to make sure we fail to start a domain on newer hypervisor with different defaults rather than silently starting a domain with different devices and hope for not breaking the guest OS. So for example, when a domain XML contains no machine type or even just an alias, such as "pc", we replace it with something real when the domain is defined. Thus when the exact same domain XML will result in different machine type depending on the QEMU version. Of course, the difference is not so drastic as in "pc" vs. "q35", but the difference is real. That said, I'm not saying we should just change our defaults just because we think a new value is better. We have have libosinfo for telling users what values are the best for their guest OS. But in case QEMU deprecates some device model or even machine type, I think we should avoid using the deprecated model as a default value to prepare people for transition. Once the deprecated model is removed, our default would change anyway, but existing domain would suddenly start to fail in case we did not change the default when the model was marked as deprecated. Of course, this would not help apps or users using transient domains without default values, but such apps/users are just broken if they rely on defaults. For persistent domains libvirt takes care of preserving default values from when a domain was first defined. Users/apps have to handle this themselves for transient apps if they care. Libvirt updates the live XML and they can read it and update their definition to make the defaults persistent. There's nothing more we can do for them and I don't think this should block us from changing any defaults. We're already doing so anyway. Jirka -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
