On 05/17/2018 03:28 PM, Jiri Denemark wrote: > On Wed, May 09, 2018 at 13:36:55 +0200, Halil Pasic wrote: >> >> >> 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. > > Right, but this differentiation is not done in the parser, so we still > need to keep the code there. However, we should be able to do so in the > appropriate PostParse function. > >> Thus b') persistent domain definition --> error or warn would >> not break the scenario you described (again AFAIU). > > I guess we could fail when a new domain is defined, but we must be extra > careful to not break backward compatibility. Alternatively we could just > drop the model name from CPU definition when a new domain is defined > (and log a warning) as suggested by Boris in another email. This > approach would be probably a bit better wrt backward compatibility since > everything would keep working. > I know it has been a while, but I have some time set aside now that I can use to look into this unless someone else feels better about tackling it. Also my apologies for the long silence. -- Respectfully, - Collin Walling -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
