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

Christian Ehrhardt christian.ehrhardt at canonical.com
Mon Aug 6 05:04:32 UTC 2018


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



> Libvirt promises to isolate applications from hypervisor changes that
> may cause incompatibilities, so we must ensure that we always use the
> "pc" machine type if it is available. Only use QEMU's own reported
> default machine type if "pc" does not exist.
>
> Note this change assumes there will always be a "pc" alias as long as a
> versioned "pc-XXX" machine type exists. If QEMU were to ship a "pc-XXX"
> machine type but not provide the "pc" alias, it is too hard to decide
> which to default so. Versioned machine types are supposed to be
> considered opaque strings, so we can't apply any sensible ordering
> ourselves and QEMU isn't reporting the list of machines in any sensible
> ordering itself.
>
> Signed-off-by: Daniel P. Berrangé <berrange at redhat.com>
> ---
>  src/qemu/qemu_capabilities.c | 19 +++++++++++++++++--
>  1 file changed, 17 insertions(+), 2 deletions(-)
>
> diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
> index 0fb800589a..9eb58afef3 100644
> --- a/src/qemu/qemu_capabilities.c
> +++ b/src/qemu/qemu_capabilities.c
> @@ -2242,6 +2242,17 @@ virQEMUCapsProbeQMPMachineTypes(virQEMUCapsPtr
> qemuCaps,
>      int ret = -1;
>      size_t i;
>      size_t defIdx = 0;
> +    ssize_t preferredIdx = -1;
> +    const char *preferredAlias = NULL;
> +
> +    /* Historically QEMU defaulted to 'pc' machine type but in
> +     * future might switch 'q35'. Such a change is considered
> +     * an ABI break from lbivirt's POV, so we must be sure to
> +     * keep 'pc' as default machine no matter what QEMU says.
> +     */
> +    if (qemuCaps->arch == VIR_ARCH_X86_64 ||
> +        qemuCaps->arch == VIR_ARCH_I686)
> +        preferredAlias = "pc";
>
>      if ((nmachines = qemuMonitorGetMachines(mon, &machines)) < 0)
>          return -1;
> @@ -2263,12 +2274,16 @@ virQEMUCapsProbeQMPMachineTypes(virQEMUCapsPtr
> qemuCaps,
>          mach->maxCpus = machines[i]->maxCpus;
>          mach->hotplugCpus = machines[i]->hotplugCpus;
>
> +        if (STREQ_NULLABLE(mach->alias, preferredAlias))
> +            preferredIdx = qemuCaps->nmachineTypes - 1;
> +
>          if (machines[i]->isDefault)
>              defIdx = qemuCaps->nmachineTypes - 1;
>      }
>
> -    if (defIdx)
> -        virQEMUCapsSetDefaultMachine(qemuCaps, defIdx);
> +    if (preferredIdx == -1)
> +        preferredIdx = defIdx;
> +    virQEMUCapsSetDefaultMachine(qemuCaps, preferredIdx);
>
>      ret = 0;
>
> --
> 2.17.1
>
> --
> libvir-list mailing list
> libvir-list at redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list



-- 
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/7de629ae/attachment-0001.htm>


More information about the libvir-list mailing list