[libvirt] Question about using cpu mode "host-model" while providing a cpu model name
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
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
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). Obviously, if anything that worked before needs to keep working as before is the main principle governing the evolution of libvirt, then replacing b) with b') is not an option. But then, neither is fixing any bug, that could be somebody's feature (https://xkcd.com/1172/). Regards, Halil
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. Jirka
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
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
On 05/09/2018 01:35 PM, Kashyap Chamarthy wrote:
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?
After the domain is defined but not started: <cpu mode='host-model' check='partial'> <model fallback='allow'>cpu-name</model> </cpu> After the defined domain is started: <cpu mode='custom' match='exact' check='partial'> <model fallback='forbid'>z13.2-base</model> <feature policy='require' name='aen'/> <feature policy='require' name='aefsi'/> <feature policy='require' name='msa5'/> <feature policy='require' name='msa4'/> <feature policy='require' name='msa3'/> <feature policy='require' name='msa2'/> <feature policy='require' name='msa1'/> <feature policy='require' name='sthyi'/> <feature policy='require' name='edat'/> <feature policy='require' name='ri'/> <feature policy='require' name='edat2'/> <feature policy='require' name='vx'/> <feature policy='require' name='ipter'/> <feature policy='require' name='esop'/> <feature policy='require' name='cte'/> <feature policy='require' name='bpb'/> <feature policy='require' name='ppa15'/> <feature policy='require' name='zpci'/> <feature policy='require' name='sea_esop2'/> <feature policy='require' name='te'/> <feature policy='require' name='cmm'/> </cpu> and of course the cpu_name does not show up in the qemu command line. The question is if the model could not simply be ignored in the define scenario resulting in <cpu mode='host-model' check='partial'> <model fallback='allow'/> </cpu> which also gets generated when just defining the domain with <cpu mode='host-model'/> -- Mit freundlichen Grüßen/Kind regards Boris Fiuczynski IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martina Köderitz Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen Registergericht: Amtsgericht Stuttgart, HRB 243294
participants (5)
-
Boris Fiuczynski -
Collin Walling -
Halil Pasic -
Jiri Denemark -
Kashyap Chamarthy