[libvirt] Question about using cpu mode "host-model" while providing a cpu model name

Jiri Denemark jdenemar at redhat.com
Wed May 9 10:41:15 UTC 2018


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




More information about the libvir-list mailing list