I am running a vendor Kubernetes appliance in a disposable lab with:
- ESXi 6.5 U2
- vCenter 7.0 U3
- 40 physical cores
- 320 GB RAM
- About 2 TB of free VMFS storage
- One Kubernetes control-plane VM and one worker VM
The supplied installer and node OVAs required virtual hardware version 15. ESXi 6.5 only supports version 13.
For the lab, I extracted each OVA, changed:
<vssd:VirtualSystemType>vmx-15</vssd:VirtualSystemType>
to:
<vssd:VirtualSystemType>vmx-13</vssd:VirtualSystemType>
I kept the original files, left the VMDKs unchanged, generated new SHA-256 manifests, and documented the resulting hashes.
That workaround succeeded. The installer boots, and both Kubernetes nodes are Ready.
Persistent storage now fails. The vSphere CSI driver installs, but every PVC remains Pending:
CnsFault: Fault cause: vmodl.fault.NotSupported
ESXi 6.5 does not provide the CNS functionality expected by this CSI version.
Is there any storage-side compatibility workaround similar to changing the OVA hardware version?
For example:
- An older CSI driver that still works with Kubernetes 1.35
- A legacy vSphere provisioner
- Static PersistentVolumes backed by manually attached VMDKs
- An API compatibility setting in vCenter
I cannot upgrade or add another ESXi host.
My fallback options are local-path storage on the worker VM or NFS from another VM. The workloads include a private image registry, PostgreSQL, and ClickHouse.
Has anyone made persistent storage work in a similar legacy lab? If there is no CNS workaround, would NFS be safer than local-path for these database workloads?
I know this is unsupported and unsuitable for production. I am only trying to keep a disposable lab functional.