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?
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@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@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list