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

Mon Aug 6 11:20:23 UTC 2018

On Mon, Aug 6, 2018 at 11:03 AM Daniel P. Berrangé <berrange at redhat.com>
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 at redhat.com>
> > 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.

> On that basis I'd ecourage you to look at whether you can phase out
> the "ubuntu" machine type alias.

The type was invented before my time, it might have been intended to NOT
imply machine types.
We kept "pc" pointing to the upstream types like pc-i440fx-2.11 and
"ubuntu" was pointing to the latest Distro type like pc-i440fx-bionic.
We could instead of the alias "ubuntu" modify the "pc" alias to alias the
particular Distro Type we want, but I always liked that we did not touch
the existing types at all :-/

Eventually we will need the same that your patch implements here, to not
break the default.
But we need that to point to the most recent Distribution type - so I have
to pick one of
 - keep ubuntu alias, use that to fall back to from libvirt
 - phase out ubuntu alias, but then "pc" would have to point to the Distro
type - I can't guarantee that back in time (new libvirt + old qemu remote)

At least it is no real type that has to be kept and "only" an alias.
I'll look at phasing out ubuntu or not - starting with an internal
discussion on the next sprint - thanks!

Thanks also for the Big picture reply - keeping the defaults sane and
establishing an per-guest opt-in via metadata sounds fine.

Regards,
> Daniel
> --
> |: https://berrange.com      -o-
> https://www.flickr.com/photos/dberrange :|
> |: https://libvirt.org         -o-
> https://fstop138.berrange.com :|
> |: https://entangle-photo.org    -o-
> https://www.instagram.com/dberrange :|
>

-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20180806/4808e4f2/attachment-0001.htm>