On 10/25/2017 12:23 PM, David Hildenbrand wrote:
On 25.10.2017 12:18, Christian Borntraeger wrote:
> Ping, I plan to submit belows patch for 2.11. We can then still look into
> a libvirt<->qemu interface for limiting host-model depending on machine
versions
> (or not).
I think this would be sufficient for now.
Having different host models, depending on the the machine type sounds
wrong. But maybe we'll need it in the future.
David, I disagree if your proposal is to generally tolerate new cpu
features in old machine types. This *might* work for gs but how do you
guaranty that guests do not behave differently/wrong when suddenly new
cpu features are made available to guest when (re-)starting them.
That is my feedback for the qemu side of this mater.
Regarding the libvirt side of this:
When looking at
https://libvirt.org/formatdomain.html#elementsCPU I
found the following sentence:
Since the CPU definition is copied just before starting a domain,
exactly the same XML can be used on different hosts while still
providing the best guest CPU each host supports.
My interpretation of "the best guest CPU each host supports" is that
besides limiting factors like hardware, kernel and qemu capabilities the
requested machine type for the guest is a limiting factor as well.
Nevertheless if my interpretation is found to be incorrect than we
should think about another new cpu mode that includes the machine type
into the "best guest CPU" detection.
My assumption is that we must not require the users to know which cpu
model they manually need to define to match a specific machine type
AND we want to guarantee that guests run without risking any side
effects by tolerating any additional cpu features.
--
Mit freundlichen Grüßen/Kind regards
Boris Fiuczynski
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martina Köderitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294