<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Sun, Aug 5, 2018 at 10:53 AM Daniel P. Berrangé <<a href="mailto:berrange@redhat.com">berrange@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">It is increasingly likely that some distro is going to change the<br>
default "x86" machine type in QEMU from "pc" to "q35". This will<br>
certainly break existing applications which write their XML on the<br>
assumption that its using a "pc" machine by default. For example they'll<br>
lack a IDE CDROM and get PCI-X instad of PCI which changes the topology<br>
radically.<br></blockquote><div><br></div><div>Hi,</div><div>Distributions carry custom manchine types for quite a while now to encapsulate differences of backports and similar [1][2].</div><div>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.</div><div><br></div><div>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.</div><div>But with the change proposed here the "default" machine type of qemu looses a lot of its (benficial) implications that that so far.</div><div><br></div><div>Ideally we'd not switch just back to "pc" here, but to something qemu can mark like a certain i400fx-abcd type.<br></div><div>I know qemu can only have one default, and it is about to change - which from a pure qemu's POV makes sense.</div><div>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.</div><div>So maybe I just modify the patch proposed here for Ubuntu to pick "ubuntu" instead of "pc" - no sure yet?</div><div><br></div><div><div style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial">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),</div><div style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial">but I wanted to know if there were some more complex considerations have been done already how those cases are supposed to be handled?</div></div><div><br></div><div>[1]: <a href="https://bugzilla.redhat.com/show_bug.cgi?id=895959">https://bugzilla.redhat.com/show_bug.cgi?id=895959</a><br></div><div>[2]: <a href="https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1294823">https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1294823</a></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Libvirt promises to isolate applications from hypervisor changes that<br>
may cause incompatibilities, so we must ensure that we always use the<br>
"pc" machine type if it is available. Only use QEMU's own reported<br>
default machine type if "pc" does not exist.<br>
<br>
Note this change assumes there will always be a "pc" alias as long as a<br>
versioned "pc-XXX" machine type exists. If QEMU were to ship a "pc-XXX"<br>
machine type but not provide the "pc" alias, it is too hard to decide<br>
which to default so. Versioned machine types are supposed to be<br>
considered opaque strings, so we can't apply any sensible ordering<br>
ourselves and QEMU isn't reporting the list of machines in any sensible<br>
ordering itself.<br>
<br>
Signed-off-by: Daniel P. Berrangé <<a href="mailto:berrange@redhat.com" target="_blank">berrange@redhat.com</a>><br>
---<br>
src/qemu/qemu_capabilities.c | 19 +++++++++++++++++--<br>
1 file changed, 17 insertions(+), 2 deletions(-)<br>
<br>
diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c<br>
index 0fb800589a..9eb58afef3 100644<br>
--- a/src/qemu/qemu_capabilities.c<br>
+++ b/src/qemu/qemu_capabilities.c<br>
@@ -2242,6 +2242,17 @@ virQEMUCapsProbeQMPMachineTypes(virQEMUCapsPtr qemuCaps,<br>
int ret = -1;<br>
size_t i;<br>
size_t defIdx = 0;<br>
+ ssize_t preferredIdx = -1;<br>
+ const char *preferredAlias = NULL;<br>
+<br>
+ /* Historically QEMU defaulted to 'pc' machine type but in<br>
+ * future might switch 'q35'. Such a change is considered<br>
+ * an ABI break from lbivirt's POV, so we must be sure to<br>
+ * keep 'pc' as default machine no matter what QEMU says.<br>
+ */<br>
+ if (qemuCaps->arch == VIR_ARCH_X86_64 ||<br>
+ qemuCaps->arch == VIR_ARCH_I686)<br>
+ preferredAlias = "pc";<br>
<br>
if ((nmachines = qemuMonitorGetMachines(mon, &machines)) < 0)<br>
return -1;<br>
@@ -2263,12 +2274,16 @@ virQEMUCapsProbeQMPMachineTypes(virQEMUCapsPtr qemuCaps,<br>
mach->maxCpus = machines[i]->maxCpus;<br>
mach->hotplugCpus = machines[i]->hotplugCpus;<br>
<br>
+ if (STREQ_NULLABLE(mach->alias, preferredAlias))<br>
+ preferredIdx = qemuCaps->nmachineTypes - 1;<br>
+<br>
if (machines[i]->isDefault)<br>
defIdx = qemuCaps->nmachineTypes - 1;<br>
}<br>
<br>
- if (defIdx)<br>
- virQEMUCapsSetDefaultMachine(qemuCaps, defIdx);<br>
+ if (preferredIdx == -1)<br>
+ preferredIdx = defIdx;<br>
+ virQEMUCapsSetDefaultMachine(qemuCaps, preferredIdx);<br>
<br>
ret = 0;<br>
<br>
-- <br>
2.17.1<br>
<br>
--<br>
libvir-list mailing list<br>
<a href="mailto:libvir-list@redhat.com" target="_blank">libvir-list@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/libvir-list" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/libvir-list</a></blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><span style="color:rgb(136,136,136);font-size:12.8px">Christian Ehrhardt</span><div style="color:rgb(136,136,136);font-size:12.8px">Software Engineer, Ubuntu Server</div><div style="color:rgb(136,136,136);font-size:12.8px">Canonical Ltd</div></div></div></div></div></div>