On Thu, 2019-10-03 at 16:00 +0200, Jiri Denemark wrote: > When starting a domain without a CPU model specified in the domain XML, > QEMU will choose a default one. Which is fine unless the domain gets > migrated to another host because libvirt doesn't perform any CPU ABI > checks and the virtual CPU provided by QEMU on the destination host can > differ from the one on the source host. > > With QEMU 4.2.0 we can probe for the default CPU model used by QEMU for > a particular machine type and store it in the domain XML. This way the > chosen CPU model is more visible to users and libvirt will make sure > the guest will see the exact same CPU after migration. > > https://bugzilla.redhat.com/show_bug.cgi?id=1598151 > https://bugzilla.redhat.com/show_bug.cgi?id=1598162 Unfortunately this will break all ppc64 guests that have been defined without specifying a CPU model, because it will result in something like <cpu mode='custom' match='exact' check='partial'> <model fallback='allow'>power8</model> </cpu> being added to the domain XML, which in turn at runtime will cause error: internal error: Unknown CPU model power8 For a while, QEMU has been reporting (and accepting) CPU models for ppc64 guests as lowercase strings, but historically they were all uppercase and our CPU map, which the user-provided CPU model is validated against, still contains those variants. For the record, our documentation[1] recommends using something like <cpu mode='host-model'> <model>power8</model> </cpu> to obtain a POWER8 CPU that can be safely migrated back and forth between POWER8 and POWER9 machines, but we can't assume everyone is following that recommendation. [1] https://libvirt.org/formatdomain.html#elementsCPU -- Andrea Bolognani / Red Hat / Virtualization -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
