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

[Daniel P. Berrangé]

On Mon, Aug 06, 2018 at 10:03:52AM +0100, Daniel P. Berrangé wrote:
> 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.
> 
> On that basis I'd ecourage you to look at whether you can phase out
> the "ubuntu" machine type alias.

Oh and on the bigger picture...

In discussions with QEMU maintainers the ultimate end goal is that we would
like all applications to be using the q35 based machine type on x86. Some
applications have support for q35 as an opt-in at user choice, but we would
like to get to a place where it is used without user having to ask for it.
The complication is that not all guest OS are compatible with it, since it
uses PCI-Express and SATA instead of IDE.

Our intention is thus to have libosinfo record metadata against each OS
saying which machine types it is capable of supporting. Mgmt applications
will thus be recommended to use libosinfo to see if q35 is supported by
the guest OS in question and use that if possible, only using the i440fx
machine for legacy OS. Furthermore when using q35 mgmt apps should avoid
adding PCI based devices (eg rtl8139), only use PCI-X capable devices
(eg e1000, virtio-net, etc). This avoids the need for PCIX-to-PCI on q35
so simplifies testing matrix for apps.

There's alot of mgmt apps out there so it will take a while to get them
all using libosinfo for this, but eventually we should get to a place
where q35 is widely used, without libvirt having to risk app breakage
by changint the default to q35 behind their back.

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 :|