This is the part I actually enjoy. The networking is done, the nested hosts are up, DNS is resolving, and now it’s time to build something that actually looks like a real vSphere environment. Deploying vCenter on a VVF lab is refreshingly simple compared to the VCF path — no SDDC Manager, no JSON bringup files, no pre-flight validation framework to argue with. You just deploy the appliance and get on with it.
That said, simple doesn’t mean you can skip the prep work. I’ve rushed this stage before and paid for it in stage 2 failures. So let me walk through what actually matters.
Before You Mount the ISO
Three things need to be sorted before the VCSA installer touches anything. Miss any of them and stage 2 will either stall or fail silently in a way that’s annoying to diagnose.
DNS. The vCenter hostname needs to resolve forward and reverse. For this lab, I’m using vc-vvf.infra.rmds.uk pointing to 10.10.20.10. Both directions. The installer will check, and it’s not forgiving. If you’re running a local DNS server on your management network (I use a small bind9 instance on a Pi), double-check the PTR record before you start. I’ve wasted 45 minutes on a stage 2 hang that turned out to be a missing reverse lookup.
NTP. vCenter is paranoid about time. It refuses to sync SSO if the clock drift between the appliance and your ESXi hosts is more than a few seconds. In a nested lab, your physical host’s time gets inherited through layers of virtualisation and it can drift. Set your NTP sources explicitly during stage 2, and make sure your nested ESXi hosts are also pointing at the same NTP server.
A host to land on. The VCSA deploys to an existing ESXi host. In a nested lab, that means picking one of your three nested hosts as the initial deployment target. I use the first host in the eventual cluster — esxi-01.infra.rmds.uk — because after the cluster is built, vCenter ends up sitting on shared storage anyway and it doesn’t matter where it started.
Stage 1: Deploying the Appliance
Mount the VCSA ISO and run the GUI installer from your workstation. On Windows this is just double-clicking the installer exe inside the ISO. On Linux or Mac, mount it and run the shell script from the vcsa-ui-installer directory.
Stage 1 is the OVA deployment. It asks you for the target ESXi host, the datastore, the network, and the appliance size. For a lab, use the Tiny deployment size — it’s designed for up to 10 hosts and 100 VMs, which is more than a nested environment will ever need. More importantly, tiny uses around 14 GB of RAM for the appliance rather than the 19 GB of a Small deployment. In a nested lab where you’re carving RAM out of a physical host, that difference matters.
Use thin provisioning on the disks. The vCenter appliance comes with a fairly aggressive storage footprint if you let it allocate thick. Thin lets the actual usage grow organically without pre-reserving 400 GB of space you’re not using today.
Stage 1 takes about 10 minutes on a decent connection. When it finishes, the appliance is sitting on your ESXi host powered on, but not yet configured. Don’t touch it yet.
Stage 2: Configuring vCenter
This is where it gets interesting. Stage 2 runs in a browser — the installer opens a connection to the appliance on port 5480 and walks you through configuration. You’ll set the SSO domain, the administrator password, NTP servers, and confirm your network settings.
A few things I always set the same way in every lab:
SSO Domain. I use vsphere.local. You could use a custom domain name, but vsphere.local is what every guide, every VMware KB, and every lab script expects. Saves friction later.
NTP. I point at my local NTP server on the management network. If you don’t have one, use the same public NTP servers your nested ESXi hosts are using. Consistency matters more than which server you pick.
SSH. Enable it. You’ll want it later when you’re troubleshooting something at 11pm and the GUI isn’t giving you enough information.
Stage 2 takes around 20 minutes. The progress bar is not a reliable indicator — it’ll sit at 78% for five minutes and then jump to done. That’s normal. Don’t cancel it.
When it completes, you get a link to the vSphere Client on https://vc-vvf.infra.rmds.uk/ui. Log in with administrator@vsphere.local and the password you just set. If you can see the inventory, stage 2 worked.
Building the Datacenter and Cluster
Right-click on the vCenter object in the inventory and create a Datacenter first. I name mine VVF-Lab. Inside that, create a Cluster. This is where you’ll want to think for a moment about what you’re enabling.
For a VVF lab cluster, enable vSphere DRS and vSphere HA from the start. You can add vSAN in the same dialog. My preference is to create the cluster with vSAN enabled in the wizard rather than adding it afterwards — it makes the storage configuration more coherent and the wizard will walk you through the disk claiming in the right order.
Leave DRS on Fully Automated. In a nested lab with three hosts, DRS will move things around occasionally, and it’s good to see it working rather than having it sit in manual mode doing nothing.
Adding the Hosts
Add your nested ESXi hosts to the cluster one at a time. Right-click the cluster, Add Hosts. You’ll need the root credentials for each host. The wizard will run a compatibility check and flag anything it doesn’t like — usually certificate warnings in a lab, which you can accept.
In my setup the three nested hosts are esxi-01, esxi-02, and esxi-03 on the management VLAN. Once they’re added, vCenter should show them as Connected and Green. If you see a yellow warning about a misconfigured advanced setting, it’s almost always an NTP drift warning. Go to each host’s Configuration tab, check the time services, and make sure they’re syncing.
Configuring vSAN
This is the part that trips people up the first time. vSAN in a nested lab requires a bit of setup that the GUI makes look easy but hides some gotchas.
Go to the Cluster → Configure → vSAN → Disk Management. You should see the disks from each nested ESXi host listed as unclaimed. In a VVF lab running on a physical host with NVMe or SSD storage, your nested disks will show up as flash. That’s what you want.
Click Claim Unused Disks. The wizard will suggest a disk grouping. For three hosts running OSA, the wizard expects one cache tier disk and two capacity tier disks per host. If you’re running ESA, there are no cache or capacity tiers — ESA pools all drives into a single flat storage layer and manages tiering internally. Review the wizard suggestions before clicking OK regardless of which architecture you’re using, since it can sometimes pick disks in the wrong order when sizes are similar.
After claiming, vSAN will build the datastore. It takes a few minutes. When it’s done, you’ll see a vsanDatastore appear in your Datastores view. Check the capacity — in my lab I get around 500 GB usable after redundancy on three 500 GB nested disks. Enough for what we need.
One thing I always check at this point: the vSAN Health. Go to Cluster → Monitor → vSAN → Skyline Health and run a check. A fresh lab cluster will show a few yellow warnings — things like network redundancy checks and HCL warnings, both expected in a nested environment. The one you don’t want to see is a red error on vSAN network connectivity. If you see that, your VMkernel adapters aren’t tagged correctly for vSAN traffic, and you need to sort that before anything else moves forward.
vMotion and vSAN VMkernel Adapters
Worth calling this out separately because it’s easy to miss. Each host needs VMkernel adapters enabled for both vMotion and vSAN traffic. Adding hosts to vCenter doesn’t configure these automatically.
Go to each host’s Configure → Networking → VMkernel Adapters. You should see vmk0 (management) already there. Add a new VMkernel adapter on your vMotion VLAN and enable the vMotion service. Do the same for vSAN — add a VMkernel on the vSAN VLAN and enable the vSAN service.
In my lab, vMotion runs on VLAN 23 and vSAN on VLAN 24, with the respective IP addresses on each host. Once all three hosts have their VMkernel adapters set up, the vSAN health warnings clear.
Smoke Test
Before moving on, run a quick sanity check. Deploy a small test VM to the vsanDatastore. Power it on. If it starts, vSAN is working. Then vMotion it to a different host. If that works, DRS and vMotion networking are clean.
The whole thing from a blank cluster to a running VM on shared vSAN storage takes about 45 minutes once you know what you’re doing. The first time it might take longer. Either way, at this point you have a working VVF cluster — three hosts, shared vSAN storage, HA and DRS enabled. That’s the foundation everything else in the VVF lab builds on.