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.
This issue was reported by a colleague of mine who was confused by the cpu features that
were available to a guest when host-model and a model name are provided. Personally, I
tend
to err on the side of providing host-model and a cpu-model-name being mutually exclusive.
I've attempted to find a solution to this problem myself by looking at
virCPUDefParseXML,
but the fact that PowerPC exists as an exception and we do not know the architecture when
parsing a guest cpu xml makes minimal code changes challenging.
If we want to make changes to the code, then I imagine that the ideal solution would
revolve
around only allowing <model>cpu-name</model> to be valid iff the cpu mode is
set to "custom".
Otherwise some clarity on the documentation would suffice. Something like "A CPU
model
specified in the domain xml will be ignored." Thoughts?
Thank you for your time.
--
Respectfully,
- Collin Walling