We are sure you are aware of the various OS patching going on to mitigate the Meltdown and Spectre security flaws.
If all your hypervisors support PCID, you can activate this for all your new VMs setting the following in your `/etc/one/vmm_exec/vmm_exec_kvm.conf` file (and restarting OpenNebula afterwards):
RAW = “<cpu mode=’host-passthrough’></cpu>”
Note that this may impair live migrations of VMs between hypervisors with heterogeneous CPUs.
The OpenNebula team is working towards an easier way to define this option on a per-VM basis, as well as support from the scheduler to pick compatible hypervisors. This will be available to the community shortly through a public maintenance release (5.4.6).
The syntax you mention is for templates, right? It is not the syntax of the conf file:
RAW = “”
is more correct?
Besides that, wouldn’t it be better to find to lowest supported processor architecture in the cluster and use that architecture? If it does not forward the pcid feature to the vm, you can add it like this:
RAW = “SandyBridge”
Hmm, in my previous comment, information is left out due to the fact that the lesser and more than characters are filtered out.
RAW = “<cpu><model>SandyBridge</model><feature policy=’optional’ name=’pcid’/></cpu>”
You are absolutely right, thanks! I’ve edited the post.
You can also set this in a VM template:
RAW = [
DATA = “”,
TYPE = “kvm” ]
This is useful for testing before you enable it in the conf file.
You need invpcid for Windows VMs to make use of this feature. I would not suggest you use a general “passthrough” option, but instead use:
You can check the Model with “virsh capabilities” on the hypervisor
Note: you _CANNOT_ live migrate VMs from a non-patched HV to a patched HV (VM will crash, seems to be paused but it isn’t!)
I tried CPU host passthrough some time ago because I needed HW-accelerated nested virtualization, but it is really unusable in heterogenous clusters. As you say, live migration does not work most of time. The rules are probably more strict than AMD versus Intel. It would be nice if ONe scheduler recognized the exact CPU features required for guest to run, and selected the new host according to them.
For now, I would strongly recommend staying away from host passthrough on heterogenous clusters.