I was working with a customer, and we were going through William Lam’s post on running VCF 9.1.1 on a single ESX host. They wanted a vSphere Supervisor so they could run VCF Private AI Services later, but only one of their hosts had GPUs in it. Buying two more GPU hosts just to meet a cluster minimum was not an option. So the question was simple: can we add a one-host cluster to the existing VCF domain and run a Supervisor on it?

The answer is yes, with a few workarounds. Before we touched their environment, I built the whole thing end to end in my Holodeck lab. This series is what I did, in the order I did it, including the parts that failed.

Lab and POC only. A one-host cluster has no redundancy, and the SDDC Manager properties below are lab workarounds, not a supported production design. Host maintenance means shutting down everything on that host.

What we are building

  • The existing management domain mgmt-a stays as it is: vCenter vc-mgmt-a, NSX Manager nsx-mgmt-a and the 4-host cluster cluster-mgmt-01a.
  • A new cluster, cluster-mgmt-02a, with one host (esx-05a) on vSAN ESA, added to that same domain.
  • A Supervisor with a single control plane VM on the new cluster.
  • NSX VPC networking with no edges: a distributed transit gateway connected to one VLAN, plus two Virtual Network Appliances (VNAs) on the existing cluster for NAT and load balancing.

No new vCenter and no new NSX Manager. Everything lands in the management domain we already had.

Lab architecture: the existing management domain, the new one-host cluster and the NSX path without edges

The Supervisor’s VPC traffic leaves through the distributed transit gateway and VLAN 22, with the two VNAs on the existing cluster as its service gateway.

Versions in my lab

ComponentVersion
SDDC Manager9.1.0.0.25371088
vCenter9.1.0, build 25370922
NSX9.1.0.0.25318225
ESXi9.1.0, build 25370933

William’s post targets 9.1.1, and my lab was on 9.1.0. The gap is smaller than I expected. His 9.1.1 cluster script still lists the single-host feature flag and the minimum cluster size as manual prerequisites on SDDC Manager, so Step 2 below applies to both versions. Only the three ESA disk-claim keys are specific to 9.1.0. Either way this is API work: per his post, the 9.1.1 UI only supports a single host for a new VCF fleet, and adding a single-host cluster to an existing domain goes through the SDDC Manager API on both versions.

The series

  1. Part 1 (this post): allowing single-host clusters in SDDC Manager
  2. Part 2: building the one-host vSAN ESA cluster
  3. Part 3: NSX VPC networking without edges
  4. Part 4: enabling a Supervisor with one control plane VM

Before you begin

  • Take a memory-less snapshot of the SDDC Manager VM. Take NSX Manager and vCenter backups too; later posts change both.
  • Make sure SDDC Manager has no running tasks. The service restart below kills whatever workflow is in flight.
  • You need SSH as vcf and the root password of the SDDC Manager appliance.

Step 1: See what SDDC Manager says today

If we send a one-host cluster spec to POST /v1/clusters/validations now, validation fails right away:

{ "errorCode": "INVALID_NUMBER_OF_HOSTS", "message": "Number of hosts is less than expected. Actual 3, Provided 1" }

SDDC Manager wants three hosts in a vSAN cluster. The properties below lower that to one.

Step 2: Set the properties

These come from William’s VCF 9.1 Installer and SDDC Manager workarounds post. The first two allow a single host, on 9.1.0 and 9.1.1 alike. The last three let vSAN ESA claim disks that are not on the HCL, which nested hosts need on 9.1.0. William’s 09/03 update says the ESA disk-claim workaround is no longer required on 9.1.1.

FileKeyWhy
/home/vcf/feature.propertiesfeature.vcf.vgl-29121.single.host.domain=trueallows a single-host domain or cluster
/etc/vmware/vcf/domainmanager/application-prod.propertiesbringup.mgmt.cluster.minimum.size=1lowers the cluster minimum
/home/vcf/feature.propertiesfeature.vcf.vgl-43370.vsan.esa.sddc.managed.disk.claim=trueESA disk claim without the HCL (9.1.0)
/etc/vmware/vcf/domainmanager/application-prod.propertiesvsan.esa.sddc.managed.disk.claim=truepairs with the line above
/etc/vmware/vcf/operationsmanager/application-prod.propertiesvsan.esa.sddc.managed.disk.claim=truepairs with the line above

Two things I ran into:

  • On 9.1.0, both application-prod.properties files are symlinks to application.properties in the same folder. Edit the real file, and back it up first.
  • In my case, the Holodeck-built SDDC Manager already had the three ESA disk-claim keys. Only the two single-host keys were missing. Check with grep before you append anything, so you don’t end up with duplicate keys.

SSH to SDDC Manager as vcf, then su -:

f=$(readlink -f /etc/vmware/vcf/domainmanager/application-prod.properties)
cp -p "$f" "$f.bak"
cp -p /home/vcf/feature.properties /home/vcf/feature.properties.bak

# add a key only if it is not there yet (the leading line break covers a file that does not end with one)
addkey() { grep -q "^$2=" "$1" || printf '\n%s=%s\n' "$2" "$3" >> "$1"; }

addkey /home/vcf/feature.properties feature.vcf.vgl-29121.single.host.domain true
addkey "$f" bringup.mgmt.cluster.minimum.size 1

# 9.1.0 with disks that are not on the HCL: the three ESA disk-claim keys as well
# o=$(readlink -f /etc/vmware/vcf/operationsmanager/application-prod.properties); cp -p "$o" "$o.bak"
# addkey /home/vcf/feature.properties feature.vcf.vgl-43370.vsan.esa.sddc.managed.disk.claim true
# addkey "$f" vsan.esa.sddc.managed.disk.claim true
# addkey "$o" vsan.esa.sddc.managed.disk.claim true

# check the result
grep -nE 'vgl-29121|vgl-43370' /home/vcf/feature.properties
grep -nE 'bringup.mgmt.cluster.minimum.size|vsan.esa.sddc.managed.disk.claim' "$f"

If a key is already there with a different value, addkey leaves it alone. Fix that line by hand.

Step 3: Restart the SDDC Manager services

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

The services restart one after another. In my case the API was answering again in under two minutes, while the restart was still going. An API that answers is not the same as a restart that is done, so wait until the script has exited and every service is back:

systemctl is-active commonsvcs domainmanager lcm operationsmanager sddc-manager-ui-app

Step 4: Prove the flag is live

The /v1/features endpoint lists every feature flag with its state. The single-host flag should show enabled: true. This needs PowerShell 7 for -SkipCertificateCheck:

$sddc  = 'sddcmanager-a.site-a.vcf.lab'
$cred  = Get-Credential administrator@vsphere.local
$body  = @{ username = $cred.UserName; password = $cred.GetNetworkCredential().Password } | ConvertTo-Json
$token = (Invoke-RestMethod -Method Post -Uri "https://$sddc/v1/tokens" -Body $body -ContentType 'application/json' -SkipCertificateCheck).accessToken
$h     = @{ Authorization = "Bearer $token" }

# the parentheses matter: the endpoint returns one JSON array, and Invoke-RestMethod passes it down the pipeline as a single object
(Invoke-RestMethod -Uri "https://$sddc/v1/features" -Headers $h -SkipCertificateCheck) |
    Where-Object name -like '*vgl-29121*'

Then run the same cluster validation again. This time it came back SUCCEEDED, and SDDC Manager was ready for a one-host cluster.

Keep the SDDC Manager snapshot until the whole series is done and verified, then delete it.

In the next post we commission the host and build the one-host vSAN ESA cluster, including the first failure of the series.