VCF 9.1 Lab Deployment Workarounds: A Practical Reference

Production VCF 9.1 deployments are validated against the Broadcom Compatibility Guide (BCG), full 3-node NSX Manager clusters, 10GbE networking, and vSAN ESA-listed hardware. Lab, POC, and educational environments almost never meet all of that — and 9.1 is measurably stricter about enforcing those checks than prior releases. The workarounds below (credit to William Lam’s field-maintained reference) are documented, supported-for-non-production configuration overrides that let you get a functional 9.1 fleet running on constrained hardware. None of these are appropriate for production — they exist specifically to unblock lab, functional-test, and training scenarios.

Every override below follows the same pattern: set a property in feature.properties or the relevant application.properties / application-prod.properties file on both the VCF Installer and SDDC Manager appliances (where applicable), then restart the corresponding service.

Enable HTTP Offline Depot Support

VCF 9.1 introduced a new, officially supported method for enabling HTTP (rather than HTTPS) access to an offline software depot that no longer requires basic authentication — useful for air-gapped or bandwidth-constrained labs pulling binaries from a local depot mirror.

Single or Dual ESX Host Deployment

If your lab has adequate per-host compute and storage, you can deploy a complete (non-nested) VCF fleet on one, two, or three ESX hosts:

feature.vcf.vgl-29121.single.host.domain = true

Set in /home/vcf/feature.properties on both VCF Installer and SDDC Manager, restarted via:

echo 'y' | /opt/vmware/vcf/operationsmanager/scripts/cli/sddcmanager_restart_services.sh

Disable the 10GbE pNIC Speed Check

enable.speed.of.physical.nics.validation = false

Set in both /etc/vmware/vcf/domainmanager/application.properties (restart: systemctl restart domainmanager) and /etc/vmware/vcf/operationsmanager/application-prod.properties (restart: systemctl restart operationsmanager).

Disable the vSAN ESA HCL Check

This is the single most commonly hit wall in nested/lab deployments — it fails with “Failed to validate vSAN HCL status” when the underlying disks aren’t on the official vSAN ESA HCL. It requires two properties set in two locations each (a step that’s easy to miss and is the most common cause of the workaround “not working” per field reports):

feature.vcf.vgl-43370.vsan.esa.sddc.managed.disk.claim = true
vsan.esa.sddc.managed.disk.claim = true

Set the first pair in /home/vcf/feature.properties, and critically, also set vsan.esa.sddc.managed.disk.claim = true in both /etc/vmware/vcf/domainmanager/application.properties and /etc/vmware/vcf/operationsmanager/application-prod.properties. Multiple field reports confirm the HCL check continues to fail if the operationsmanager file is skipped — this was originally undocumented and was added to the reference after community verification.

Disable vMotion and vSAN Connectivity Checks

For labs where connectivity is functionally fine but fails automated validation (common with flat/nested networking):

validation.disable.vmotion.connectivity.check = true
validation.disable.vmotion.l3.gateway.connectivity.check = true
validation.disable.vsan.connectivity.check = true

All in /etc/vmware/vcf/domainmanager/application.properties, restart domainmanager.

Disable ESX TEP MTU Check

validation.disable.network.connectivity.check = true
nsxt.mtu.validation.skip = true

Same file/restart as above — useful where jumbo-frame MTU can’t be guaranteed end-to-end in a nested lab switch fabric.

Single ESX Host with NFS Principal Storage

validation.disable.nfs.configuration.connectivity.check = true

Same file/restart pattern, for labs using NFS rather than vSAN as principal storage on a single host.

Single-Node Avi Load Balancer

feature.vcf.vgl-41078.alb.single.node.cluster = true

In /etc/vmware/vcf/domainmanager/application.properties, restarted via the SDDC Manager restart script — lets you deploy a functional (non-HA) Avi controller instead of the production 3-node cluster.

Timeout Extensions

Resource-constrained labs frequently hit timeouts rather than hard validation failures. The relevant knobs, all in domainmanager/application.properties with a systemctl restart domainmanager:

Field Notes Worth Knowing

• Converge/Convert scenarios with existing NSX 4.x deployments default to requiring a 3-node NSX Manager cluster even when the source environment ran single-node NSX. The workaround is to export the JSON deployment spec before finalizing, manually strip the extra NSX Manager node entries from the array, and re-import — there is currently no UI toggle for this in the convert flow, and internal guidance suggests principal storage choice (vSAN vs. external) may influence whether this check is enforced.
• Kubernetes worker sizing for the new Management Services cluster is CPU/memory-hungry (12 vCPU workers by default) and is a common wall on small home-lab hardware (e.g., 3-node Intel NUC clusters). VVF (VMware vSphere Foundation) deploys a lighter VCFMS footprint (1 control-plane + 2 workers, expanding to 3 workers only if Log Management is enabled) — worth considering VVF instead of full VCF for pure lab/education purposes where VCF-specific entitlement features aren’t required.
• These properties should be treated as a living reference — Broadcom and the community continue to refine them release over release, so re-check the source before every new deployment cycle rather than relying on a cached copy.

The Standard Caveat

Every one of these is a validation bypass, not a supported production configuration. Applying any of them to a production or even pre-production customer environment should be treated as a deviation requiring explicit sign-off, and rolled back (or the environment rebuilt clean) before go-live.