On Thu, Oct 04, 2018 at 14:13:41 +0100, Daniel P. Berrangé wrote: > The problem with saying applications were doing it "wrong" is that > this definition of "wrong" changes. Applications were perfectly > justified in not providing a machine type, because the concept > didn't even exist in earlier libvirt. Once it did exist, we still > only supported x86, and there was no q35, so it was still valid to > not specify it. > > Even today it is reasonable to not care about machine type in case > where the app only cares about x86. > > Our view of "best" way to configure a guest is changing and in many > cases it is becoming increasingly clear that there's no single > "best" way, or no single perfect default. As I tried to explain in another mail in this thread, I definitely agree we should not change defaults just because we think some value is better now. That's really a job for libosinfo. But what if QEMU (or any other hypervisor) marks something (device model, machine type) as deprecated and we use that deprecated value as our default. Shouldn't we be able to tell about it to our users (here runtime warnings could help) when they use such thing explicitly and choose a different default value? That would help users with the transition and once hypervisor drops support for it completely, fewer existing domains will be affected since the recently created ones would already use non-deprecated defaults. We already silently do this to some extent with machine types. If a users specifies "pc" or even nothing, we translate it to the current QEMU default machine type "pc-i440fx-*". So taking "q35" as an example, if QEMU marks i440fx machine types as deprecated (they seem to be thinking about it) I don't see that big difference[*] in changing the default machine type to "q35". After all we will automatically change the default once i440fx is removed completely. [*] sure some devices don't even exist in q35 machine types some domain XMLs may not work anymore while with just newer i440fx machine type the XML would just keep working. But the guest OS will see a different hardware anyway and may be unhappy about it. Jirka -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
