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

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).