While I was testing Broadcom’s new Release 8.0.3, I encountered some issues getting my nested lab to work in a Proxmox environment. Despite enabling Nested Virtualization on all Proxmox nodes and setting the VM CPU type to ‘host,’ the vCLS service wouldn’t start due to EVC issues, causing DRS to malfunction.
Troubleshooting Nested Virtualization
First, I checked whether nested virtualization was enabled on the Proxmox nodes. This can be verified with the following command:
root@pve0:~# cat /sys/module/kvm_intel/parameters/nested Y
Next, I ensured the CPU type was set to ‘host’:
Finally, I checked if the ESXi node reported HV enabled:
[root@esx3:~] esxcfg-info|grep "HV Support" |----HV Support............................................3
- 0 - VT/AMD-V support is not available for this hardware.
- 1 - VT/AMD-V might be available but is not supported for this hardware.
- 2 - VT/AMD-V is available but is not enabled in the BIOS.
- 3 - VT/AMD-V is enabled in the BIOS and can be used.
Deeper Look into vCLS
Since version 8.0.3, vCLS 2.0 is active, meaning the vCLS VMs are now Pods instead of traditional VMs. The issue is that the Pods configuration cannot be altered in any documented way. Therefore, I looked into reverting to the “old” vCLS model.
Solution
To disable the new vCLS version and revert to the old one, I found an advanced vCenter option. Follow these steps:
- Navigate to
vCenter > Configure > Advanced Settings
. - Set
config.vcls.disablePodCrx
totrue
(default isfalse
).
With this change, vCLS is deployed as VMs again. You can now change the EVC settings of the VMs after upgrading their VM compatibility to vSphere 8.0.2.
Conclusion
I hope Broadcom addresses this problem or at least documents an official way to work around it. This issue is a significant roadblock for homelabbers like me who use non-ESXi based host systems on their hypervisors. I suspect the same problem might occur on unsupported CPUs, which are also widespread in the homelab community.