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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, May 08, 2018 at 10:44:22AM -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>

After starting the guest, you still see the same as above when you do
`virsh dumpxml $GUEST`?  Also does the "cpu-name" of your choice really
shows up when check the QEMU command-line for the guest?

> 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?

I'd wait for Jiri Denemark to chime in with a more detailed response.

While at it, that whole 'host-model' section could be clarified and
updated to be more readable (if you wrap that at 72 lines, it ends up
being a huge 30-line unreadable paragraph). I keep intending to do that,
but never got around so far.

-- 
/kashyap

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list



[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]

  Powered by Linux