On 05/09/2018 12:41 PM, Jiri Denemark wrote:
On Tue, May 08, 2018 at 10:44:22 -0400, Collin Walling wrote:
Hi
I have noticed something that may be misconstrued regarding the libvirt domain
xml format
for defining a cpu model. There seems to be a misalignment where the libvirt
documentation
states something that is not supported, but libvirt itself gives no clear
indication of
such. This is regarding the cpu mode "host-model" and providing a cpu model
name between
the <model> tags.
>From the libvirt docs under header "CPU model and topology" paragraph "cpu"
subparagraph
"host-model", the following rule is defined (bolded or between asterisks):
"... The match attribute can't be used in this mode. *Specifying CPU model is
not supported*
either, but model's fallback attribute may still be used. ..."
https://libvirt.org/formatdomain.html#elementsCPU
The above rule reads as "if mode is 'host-model' (and the architecture is not
PowerPC) then
specifying a model name should not be allowed". However, this is not the
observed behavior.
For example, I can define and start a guest with the following xml snippet
without any issues:
<cpu mode='host-model'>
<model>cpu-name</model>
</cpu>
Which seems to contradict what the documentation states.
It's not forbidden for compatibility reasons. Old libvirt used to fill
in the <model>...</model> in <cpu mode='host-model'></cpu> during
migration and save/restore so that the destination would know the actual
CPU the domain was started with. We changed this so that host-model
automatically turns into mode='custom' CPU when a domain starts, but we
still need to support parsing the XML whare mode='host-model' and
<model></model> are used at the same time. When a domain is migrated,
libvirt will turn the incoming host-model into custom mode. Otherwise
the specified model will just be ignored.
Jirka
Thank you very much for your explanation. AFAIU we already differentiate
between:
a) 'incoming migration' (~ transient domain definition) --> convert to 'custom'
b) 'otherwise' (~ persistent domain definition) --> ignored.
Thus b') persistent domain definition --> error or warn would
not break the scenario you described (again AFAIU).
Obviously, if anything that worked before needs to keep
working as before is the main principle governing the evolution of
libvirt, then replacing b) with b') is not an option. But then, neither is
fixing any bug, that could be somebody's feature (https://xkcd.com/1172/).
Regards,
Halil
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
