Re: [libvirt] [PATCH] qemu: ensure "pc" machine is always used as default if available

On Mon, Aug 6, 2018 at 11:03 AM Daniel P. Berrangé <berrange(a)redhat.com&gt; wrote: > On Mon, Aug 06, 2018 at 07:04:32AM +0200, Christian Ehrhardt wrote: > > On Sun, Aug 5, 2018 at 10:53 AM Daniel P. Berrangé <berrange(a)redhat.com&gt; > > wrote: > > > > > It is increasingly likely that some distro is going to change the > > > default "x86" machine type in QEMU from "pc" to "q35". This will > > > certainly break existing applications which write their XML on the > > > assumption that its using a "pc" machine by default. For example > they'll > > > lack a IDE CDROM and get PCI-X instad of PCI which changes the topology > > > radically. > > > > > > > Hi, > > Distributions carry custom manchine types for quite a while now to > > encapsulate differences of backports and similar [1][2]. > > That said, in all those "pc" isn't the default for a long time and it was > > actually quite comfortable to be able to switch the default from qemu > where > > changes take place and not having to touch libvirt in that regard. > > > > I agree that pc->q35 is a "bigger" switch in terms of default behavior > than > > default enabling a single new feature out of the i440fx scope, therefore > I > > understand the preference of libvirt to preserve the old default. > > But with the change proposed here the "default" machine type of qemu > looses > > a lot of its (benficial) implications that that so far. > > > > Ideally we'd not switch just back to "pc" here, but to something qemu can > > mark like a certain i400fx-abcd type. > > I know qemu can only have one default, and it is about to change - which > > from a pure qemu's POV makes sense. > > We always carried an alias "ubuntu" that changed with each release and > > pointed to the preferred default type, just like "pc" pointed to the most > > recent pc-i440 type. > > So maybe I just modify the patch proposed here for Ubuntu to pick > "ubuntu" > > instead of "pc" - no sure yet? > > > > Or we can carry a revert of the patch discussed here (but then would get > > all the pain of old working XML tools failing, doesn't sound like a good > > option), > > but I wanted to know if there were some more complex considerations have > > been done already how those cases are supposed to be handled? > > > > [1]: https://bugzilla.redhat.com/show_bug.cgi?id=895959 > > [2]: https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1294823 > > There's multiple things at play. First all the canonical machine type > names which are versioned > > pc-i440fx-2.5.0 > pc-i440fx-2.6.0 > pc-i440fx-2.7.0 > ... > pc-i440fx-2.10.0 > pc-q35-2.5.0 > pc-q35-2.6.0 > pc-q35-2.7.0 > ... > pc-q35-2.10.0 > > Then there are the convenient aliases mapping to the most recent versioned > machine type > > pc -> pc-i440fx-2.10.0 > q35 -> pc-q35-2.10.0 > > Finally, the versioned machine type that is resolved by the "pc" alias > is listed as the default. > > Even when distros ship custom machine types this has little to no impact > on applications. It generally just means the version number part of the > machine type changes. 'pc' still resolves to the most recent versioned > machine type, and is listed as the default. > > The key thing is that applicatons (virt-install, virt-manager, oVirt, > OpenStack, etc) need to know whether they're using "pc" or "q35" when > building guest XML, as that difference is used to trigger different > code paths. > > In looking at the code for various mgmt apps we see alot of patterns > like > > if machine != NULL & strstr(machine, "q35") > ...write XML suitable for q35... > else > ...write XML suitable for pc... > > IOW, the application is assuming that if the user hasn't requested an > explicit type, they'll get "i440fx" based "pc". > > If QEMU changes its default so that the "q35" alias is marked as the > default, then this will break every single mgmt application that we > have looked at. This is exactly the kind of thing that libvirt promises > will not happen to mgmt apps, so we must guarantee that if no machine > type is listed in the XML, then app will always get the i440fx based > "pc" machine, and not "q35". > > WRT your point about the "ubuntu" machine type. I think using such a > machine type name is not a desirable thing todo. No application that > I've looked at, nor libvirt itself, has logic to know whether "ubuntu" > machine type is based on i440fx or q35 chipsets. I expect that, by > luck, they'll mostly end up treating it as i440fx based, since most > apps do an explicit check for "q35" in the name and assume everything > else is i440fx. > > So the general guidance we give is it that distros should honour the > QEMU machine type name prefixes "pc-q35-" and "pc-i440fx-", and only > ever change the version suffix if they want to add custom distro > specific variants. ie don't invent new prefixes, nor new aliases, > as no application will know what todo with those. > IMHO new aliases are actually fine, as they will never stay the alias but be resolve on first definition. If a management App/User knows about them it is free to pass them, but then gets mapped to the more defined names automatically. If App/User didn't know about them, then hopefully they won't specify it and use the full definitions. The real Distribution machine types in the Ubuntu case already follow the preferred prefix-known like pc-i440fx-... and pc-q35-... pattern.