Goal

Have a cluster level baseline CPU model.
Analogous to what host-model is to a node, cluster-model should be to the cluster.
It is an alias to that cpu model which is available on all workload nodes of the cluster. Thus the common CPU model denominator of all nodes.
The term `cluster-model` can be used in the VMI API as a CPU model and KubeVirt CR as the default CPU model.

This CPU model should become the CNV - and KubevIrt eventually - default, this will effectively change CNV's stance from being "highest performing" out of the box (with host-model) to "compatible and high performing" (with cluster-model).

Thoughts

• In contrast to host-model, cluster-model could expand to a real cpu name (and not to a set of flags as host-model does)
• If cluster-mnodel expands to a cpu model name, then nesting will not be available out of the box anymore. host-model or a VMI level override with requesting vmx/svm flags is needed for this. Or a custom flavor
• VMware call this EVC

User Stories

• As a cluster admin I want CNV to make the best out of my set of nodes so that I can simply (without configuration) run VMs.
• By default cluster-model CPU model will be set in the KubeVirt CR so that whenever a VM is started the then relevant cluster-nodel will be used

Non-Requirements

• List of things not included in this epic, to alleviate any doubt raised during the grooming process.

Notes

• Today's system behavior is, that the KubeVirt defautl cpuModel will be set on the VMI (not VM) upon it's creation. Assuming that cluster-model becomes available, this would mean, that the cluster-model is set/used whenever a VM is getting started. Thus a restart of a VM could lead to a CPU model change, but at the same time would ensure that a new CPU model is picked up, once the cluster sees ie. an update
• Train of thought: https://docs.google.com/presentation/d/1fe40SeyJ0lhrY4A6BGxH5vaBBYRLJwjjBDZ1l648swE/edit#

Done Checklist