Infrastructure / VMware Cloud Foundation / Tintri

A Solutions Architect’s ground-up design and deployment guide. From the white-board diagram to a validated private cloud, with every PowerShell and Python command you need.

Level: Beginner to intermediatePlatform: VCF 9.0 / 9.1Storage: Tintri VMstore NFSv3

VCF InstallerNFSv3 principal storageVCF.PowerCLIPowerVCFVAAI-NASPython REST

What this guide covers

1. VCF 9 architecture for newcomers
2. Why NFS and Tintri as principal storage
3. The design phase: thinking like an architect
4. Network and storage design
5. Pre-deployment preparation
6. Management domain bring-up on NFS
7. PowerShell automation with VCF.PowerCLI
8. ESXi and Tintri NFS tuning
9. Validation with PowerShell and Python
10. Design decisions, at a glance
11. Pitfalls and lessons learned
12. Wrap-up and next steps

VMware Cloud Foundation (VCF) is the integrated software-defined data center stack from Broadcom. It bundles vSphere, vSAN, NSX, and the management plane into one lifecycle-managed platform. VCF 9 was the largest re-architecture of the product since its inception, and if you are coming to it fresh, the first hurdle is simply understanding how the pieces fit together before you touch a single host.

This guide takes the approach a Solutions Architect would take on a real engagement. We do not start by clicking through an installer. We start with a design, decide deliberately why we are using Tintri VMstore over NFS as our principal storage instead of vSAN, document every choice, and only then deploy and automate. By the end you will have a working management domain and a virtual infrastructure workload domain, both backed by Tintri NFS, plus reusable PowerShell and Python to repeat the build.

Who this is for

Anyone learning VCF who already has working knowledge of ESXi, vCenter, and basic networking. You do not need prior VCF experience. Where a concept is VCF-specific, it is explained the first time it appears.

01VCF 9 architecture for newcomers

Older VCF releases kept the components somewhat loosely coupled and used SDDC Manager as the primary console. VCF 9 reorganized everything into a fleet-level model with a single operating experience. Before designing anything, learn this vocabulary, because the installer and the documentation assume it.

The building blocks

• VCF Fleet is the top-level construct. A fleet can span one or many VCF instances and provides centralized, cross-instance management.
• VCF Instance is a single SDDC deployment. Each instance contains its own vCenter, NSX Manager, SDDC Manager, and one or more vSphere clusters.
• VCF Operations (formerly Aria Operations) is the central console for the fleet. In VCF 9 it replaces the standalone SDDC Manager user interface as the place you do most day-to-day work: monitoring, lifecycle, capacity, and cost.
• VCF Automation (formerly Aria Automation) provides self-service provisioning and a service catalog. It is deployed with the full VCF license.
• Management Domain is the first thing you build. It hosts the management appliances themselves: vCenter, NSX, SDDC Manager, Operations, and Automation.
• VI Workload Domain is where your actual workloads run. It has its own vCenter and clusters and can use a different storage type from the management domain.

VCF FLEET +—————————————————————+ | VCF Operations (central console) VCF Automation | +—————————————————————+ | | v v +————————-+ +—————————–+ | VCF INSTANCE | | (additional instances) | | | | | | Management Domain | | | | – SDDC Manager | | | | – vCenter (mgmt) | | | | – NSX Manager | | | | – ESXi hosts | | | | – PRINCIPAL STORAGE –[ Tintri VMstore NFS datastore ] | | | | | | VI Workload Domain | | | | – vCenter (workload) | | | | – NSX Manager | | | | – ESXi hosts | | | | – PRINCIPAL STORAGE –[ Tintri VMstore NFS datastore ] | +————————-+ +—————————–+

The VCF Installer

VCF 9 introduced a unified appliance called the VCF Installer, which replaces the older Cloud Builder. It is delivered as a single OVA, and the previous Excel-based Deployment Parameter Workbook is gone. You drive the first deployment, called the bring-up, either through a guided wizard in the installer interface or by uploading a JSON specification file. The wizard performs input validation up front, which catches many of the errors that used to surface only during deployment. You can also export the JSON from the wizard so the build becomes repeatable.

Key takeaway

You build the management domain first using the VCF Installer. Everything else, including workload domains, is added afterward from VCF Operations or the SDDC Manager APIs. Get the management domain right and the rest follows.

02Why NFS and Tintri as principal storage

VCF historically required vSAN for the management domain. That is no longer the case. VCF 9 expanded the supported principal storage types significantly, which is exactly what makes a Tintri-backed design possible end to end.

What VCF 9 supports as principal storage

Critical version detail

VCF supports NFS protocol version 3 only as principal storage. NFSv4.1 is allowed for supplemental datastores but not as the principal datastore for a domain or cluster. Tintri VMstore presents NFSv3, so this aligns perfectly, but it is the single most common thing people get wrong on their first design.

Why Tintri VMstore fits the role

Tintri VMstore is a VM-aware NFS array. Rather than carving out many LUNs or volumes, it presents a single NFS datastore to vCenter and manages granularity at the level of the individual virtual machine. For a VCF design this brings several advantages:

• One datastore, no LUN math. A single export removes the guesswork of how many datastores to create, which keeps the VCF storage layout simple.
• Per-VM quality of service, snapshots, and replication. Operations are scoped to the VM, not the volume, which is far more natural for a cloud platform.
• VAAI-NAS offload. Tintri implements the NFS VAAI primitives, so clone and space operations are offloaded to the array. This matters for provisioning speed and host CPU.
• Independent scaling. Storage scales separately from compute. You add VMstore capacity without touching the cluster, and you add hosts without re-architecting storage. This is the headline reason an architect chooses external NFS over a hyperconverged design.
• Reuse of existing investment. If Tintri is already in the data center, principal NFS lets VCF consume it directly instead of standing up a parallel vSAN island.

03The design phase: thinking like an architect

A deployment that starts in the installer tends to end in a rebuild. Start with a design document. The goal of this phase is to make every decision on paper, validate it against requirements and the bill of materials, and produce the inputs the installer will ask for. The installer should feel like data entry, not decision making.

Step 1: Capture requirements

Write down the answers to these before anything else. They drive every later choice.

• How many workloads, and what is their compute and storage profile?
• What availability target applies (single site, stretched, recovery)?
• What is the existing network: VLAN scheme, routing, MTU capability?
• What Tintri VMstore models are available and what is their usable capacity?
• Is this a lab or production build? This sets host counts and sizing.

Step 2: Choose the topology

VCF supports a standard architecture, with the management domain separated from one or more workload domains, and a consolidated architecture where workloads share the management domain. For anything beyond a small lab, use the standard architecture. It isolates the management plane and lets the workload domain scale and be patched independently.

REFERENCE TOPOLOGY (this guide) —————————————————————- Management Domain (mgmt-vc01) VI Workload Domain (wld01-vc01) ESXi x4 ———-+ ESXi x4 ———-+ Tintri NFS export | Tintri NFS export | /vcf-mgmt | /vcf-wld01 | | | Both domains consume Tintri VMstore NFSv3 as PRINCIPAL storage. Compute scales by adding hosts; capacity scales on the VMstore.

Host count note

With external NFS, the VCF Installer accepts a minimum of 2 ESXi hosts for the management domain, versus 3 for vSAN. For production, 4 hosts per domain is the practical floor: it gives you headroom for maintenance plus one host failure. This guide assumes 4 per domain.

Step 3: Build the bill of materials check

Every VCF release ships a Bill of Materials (BOM) that pins the exact ESXi, vCenter, NSX, and SDDC Manager versions. Your ESXi hosts must be imaged to the exact build in the BOM for your VCF version before the installer will accept them. Confirm the BOM in the release notes for your target build and record the ESXi version as a design input.

04Network and storage design

This is where most NFS-backed VCF deployments succeed or fail. NFS performance and stability live and die by the network design, so an architect treats it as a first-class deliverable.

VLAN and VMkernel layout

Plan a dedicated VLAN per traffic type. VCF uses a network pool to hand out IPs for the non-management traffic types during host commissioning, so define these ranges now.

Jumbo frames must be end to end

Set MTU 9000 on the NFS VMkernel, the virtual switch, the physical switch ports, and the Tintri VMstore data interface. A single device left at 1500 produces silent packet fragmentation and severe, hard-to-diagnose NFS latency. Validate it before deploying, not after.

NFS-specific design rules

• Dedicate the NFS VMkernel. Do not share the VMstore data network with management, vMotion, or fault tolerance traffic. NFS gets its own VMkernel port on its own VLAN.
• Enable VMkernel binding for the NFS datastore. The installer offers this toggle. With binding, if the VMkernel adapter used for NFS fails, traffic is not silently re-routed out the wrong adapter.
• Plan a static route if NFS is on a separate L3 network. When the VMstore lives on a routed subnet, add a static route so NFS traffic egresses the correct VMkernel rather than the management default gateway.
• One export per domain. Present one Tintri NFS export per domain as the principal datastore. Additional VMstore exports can be mounted later as supplemental storage.

Storage sizing

Size the principal datastore for the management appliances plus growth. The management domain in VCF 9 with the full stack is heavy: VCF Automation alone wants 24 vCPUs to boot a single node, and Operations and the other appliances add up. Budget the management export generously, on the order of several terabytes, and size the workload export to the workload profile from Step 1.

Design decisions, captured

Record decisions as you go. A short decision register turns into your as-built documentation and saves the next engineer hours. We compile the full register in section 10.

05Pre-deployment preparation

The installer validates aggressively. Most validation failures are environmental: DNS, NTP, or MTU. Clear these before you start.

PREP 1

DNS forward and reverse records

Create both forward (A) and reverse (PTR) records for every appliance and host: the VCF Installer, SDDC Manager, both vCenters, NSX Manager nodes, VCF Operations, VCF Automation, and every ESXi host. The installer validates DNS by reverse lookup, so the PTR records must resolve, not just the A records.

PowerShell: validate DNS forward and reverse

# Run from a Windows admin workstation that uses the same DNS as VCF.
$fqdns = @(
  "vcf-installer.lab.local",
  "sddc-mgr.lab.local",
  "mgmt-vc01.lab.local",
  "wld01-vc01.lab.local",
  "nsx-mgmt01.lab.local",
  "vcf-ops01.lab.local",
  "vcf-auto01.lab.local",
  "esxi-m01.lab.local","esxi-m02.lab.local",
  "esxi-m03.lab.local","esxi-m04.lab.local"
)
foreach ($name in $fqdns) {
  try {
    $a = (Resolve-DnsName $name -Type A -ErrorAction Stop).IPAddress
    $ptr = (Resolve-DnsName $a -Type PTR -ErrorAction Stop).NameHost
    $ok = if ($ptr -eq $name) { "MATCH" } else { "PTR MISMATCH" }
    "{0,-26} {1,-15} -> {2}  [{3}]" -f $name,$a,$ptr,$ok
  } catch {
    "{0,-26} FAILED to resolve" -f $name
  }
}

PREP 2

NTP, and confirm reachability and MTU

Configure a reachable NTP server, the same one across all hosts and appliances. Then prove jumbo frames work to the VMstore data interface from each host. A successful large unfragmented ping is the cheapest insurance in this entire project.

ESXi shell: confirm jumbo MTU to the Tintri data interface

# From each ESXi host, ping the VMstore NFS data IP with a 8972-byte
# payload and the do-not-fragment flag set. 8972 + headers = 9000.
vmkping -I vmk2 -d -s 8972 10.16.13.50
# Success looks like normal replies. If you see "sendto() failed
# (Message too long)" then an MTU somewhere in the path is still 1500.

PREP 3

Prepare the Tintri VMstore

On the VMstore, configure the data network interface on the NFS VLAN with MTU 9000, register vCenter as a hypervisor manager so the array becomes VM-aware, and create the NFS exports for the management and workload domains. Confirm the ESXi host management or NFS subnets are permitted to mount the exports.

Do not pre-mount on the hosts

Create and export the NFS share on the VMstore, but do not configure an NFS VMkernel adapter on the ESXi hosts and do not mount the datastore before running the installer. A pre-existing NFS VMkernel or a pre-mounted datastore causes the installer validation checks to fail. The installer creates the VMkernel and mounts the datastore for you.

PREP 4

Image the ESXi hosts to the BOM build

Install the exact ESXi version from your VCF BOM on every host. Give each host a static management IP, the correct DNS and NTP, and an SSH-enabled root account. Leave the NFS VMkernel unconfigured per the warning above. Confirm hardware time is correct, because clock skew is another frequent validation failure.

06Management domain bring-up on NFS

With prep complete, deploy the VCF Installer appliance and run the bring-up. The walkthrough below is the wizard path. We export the JSON at the end so the build is repeatable, and section 7 shows the API and PowerShell equivalents for the workload domain.

STEP 1

Deploy the VCF Installer OVA

Deploy the installer OVA to a temporary or existing host that can reach the management network and the VMstore. Power it on, browse to its interface, and download or stage the software binaries for the VCF version you are deploying.

STEP 2

Start a new fleet bring-up

Choose to deploy a new VCF fleet. For a greenfield build, leave the existing-components options unchecked. Configure NTP first under time configuration, since the wizard validates it early.

STEP 3

Enter hosts, networking, and FQDNs

Add the ESXi hosts that will form the management domain and accept the auto-populated SSL thumbprints. Enter the network settings matching your VLAN design. Enter the vCenter FQDN, datacenter name, and cluster name. The wizard relies on DNS reverse lookup from the installer, which is why PREP 1 matters.

STEP 4

Select NFS v3 as principal storage

This is the decisive step for a Tintri build. On the storage page, select NFS v3 rather than vSAN. Provide the VMstore NFS server IP or FQDN and the export path, for example /vcf-mgmt. Enable the Configure VMkernel Binding for NFS Datastore option so NFS traffic stays pinned to its adapter.

VCF Installer JSON: the storage section for NFSv3

// Excerpt from the exported bring-up spec. Field names follow the
// VCF 9 installer schema; export your own spec to confirm exact keys.
{
  "datastoreSpec": {
    "nfsDatastoreSpec": {
      "nasVolume": {
        "serverName": ["10.16.13.50"],
        "path": "/vcf-mgmt",
        "readOnly": false,
        "userTag": "vcf-mgmt-ds"
      },
      "datastoreName": "ds-mgmt-tintri-nfs",
      "vmkBindingEnabled": true
    }
  }
}

STEP 5

Review, export JSON, deploy

On the summary page, expand each component and confirm the inputs. Download the JSON specification for reuse and automation. Start the deployment. The installer validates first, then deploys SDDC Manager, the management vCenter, NSX, and the full VCF Operations and Automation stack. When it finishes, it returns the VCF Operations login URL. Record the auto-generated passwords if you let it generate them.

Repeatability

The exported JSON is your blueprint. Store it in version control next to your design document. A future rebuild becomes upload-and-validate rather than re-entering dozens of fields.

07PowerShell automation with VCF.PowerCLI

Once the management domain is up, adding a workload domain is a perfect automation target. VCF 9 ships a unified module, VCF.PowerCLI, and the long-standing community module PowerVCF wraps the SDDC Manager APIs with friendly cmdlets. We use both: VCF.PowerCLI for the modern unified verbs and PowerVCF for concise workload-domain operations.

PS 1

Install the modules

PowerShell: install VCF automation modules

# Run PowerShell as Administrator.
Install-Module -Name VCF.PowerCLI -Scope CurrentUser -Force
Install-Module -Name PowerVCF      -Scope CurrentUser -Force
# Optional: generates JSON specs from the Planning and Preparation workbook.
Install-Module -Name VCF.JSONGenerator -Scope CurrentUser -Force
# Skip the CEIP prompt for unattended runs.
Set-PowerCLIConfiguration -Scope User -ParticipateInCEIP $false -Confirm:$false

PS 2

Connect to SDDC Manager

PowerShell: authenticate to SDDC Manager

$sddc     = "sddc-mgr.lab.local"
$user     = "administrator@vsphere.local"
$pass     = Read-Host "SSO password" -AsSecureString
$plain    = [System.Net.NetworkCredential]::new("", $pass).Password
Request-VCFToken -fqdn $sddc -username $user -password $plain
# Sanity check: list the hosts already known to SDDC Manager.
Get-VCFHost | Format-Table fqdn, status, @{n="Storage";e={$_.storageType}}

PS 3

Create a network pool that includes NFS

The network pool supplies vMotion and NFS addressing during host commissioning. Define it once, then reuse it for every host in the domain.

PowerShell: build and submit a network pool spec

$poolBody = @{
  name = "wld01-pool"
  networks = @(
    @{
      type    = "VMOTION"
      vlanId  = 1612
      mtu     = 9000
      subnet  = "10.16.12.0"
      mask    = "255.255.255.0"
      gateway = "10.16.12.1"
      ipPools = @(@{ start = "10.16.12.101"; end = "10.16.12.140" })
    },
    @{
      type    = "NFS"
      vlanId  = 1613
      mtu     = 9000
      subnet  = "10.16.13.0"
      mask    = "255.255.255.0"
      gateway = "10.16.13.1"
      ipPools = @(@{ start = "10.16.13.101"; end = "10.16.13.140" })
    }
  )
}
New-VCFNetworkPool -json ($poolBody | ConvertTo-Json -Depth 6)
$pool = Get-VCFNetworkPool | Where-Object { $_.name -eq "wld01-pool" }
"Network pool id: $($pool.id)"

PS 4

Commission the workload hosts with NFS storage type

Hosts must be commissioned with the storage type they will use. For a Tintri NFS workload domain, commission them as NFS, bound to the network pool above.

PowerShell: commission hosts as NFS

$hosts = @(
  "esxi-w01.lab.local","esxi-w02.lab.local",
  "esxi-w03.lab.local","esxi-w04.lab.local"
)
$commissionSpec = $hosts | ForEach-Object {
  @{
    fqdn            = $_
    username        = "root"
    password        = "ESXiRootPassword"
    storageType     = "NFS"
    networkPoolId   = $pool.id
  }
}
$task = New-VCFCommissionHost -json ($commissionSpec | ConvertTo-Json -Depth 6)
# Poll the task until it leaves the IN_PROGRESS state.
do {
  Start-Sleep 20
  $t = Get-VCFTask -id $task.id
  "Commission status: $($t.status)"
} while ($t.status -eq "IN_PROGRESS")

PS 5

Create the VI workload domain on NFS

Now assemble the workload domain specification. The principal storage block points at the Tintri export. Submit it and poll the long-running task.

PowerShell: workload domain spec with NFSv3 principal storage

$commissioned = Get-VCFHost | Where-Object {
  $_.status -eq "UNASSIGNED_USEABLE" -and $_.fqdn -like "esxi-w*"
}
$wldSpec = @{
  domainName = "wld01"
  vcenterSpec = @{
    name              = "wld01-vc01"
    networkDetailsSpec = @{
      ipAddress = "10.16.11.40"
      dnsName   = "wld01-vc01.lab.local"
      gateway   = "10.16.11.1"
      subnetMask = "255.255.255.0"
    }
    rootPassword = "VcServerRootPw"
  }
  computeSpec = @{
    clusterSpecs = @(
      @{
        name = "wld01-cl01"
        hostSpecs = @(
          $commissioned | ForEach-Object {
            @{ id = $_.id; licenseKey = "" }
          }
        )
        datastoreSpec = @{
          nfsDatastoreSpecs = @(
            @{
              datastoreName = "ds-wld01-tintri-nfs"
              nasVolume = @{
                serverName = @("10.16.13.51")
                path       = "/vcf-wld01"
                readOnly   = $false
              }
            }
          )
        }
      }
    )
  }
  nsxTSpec = @{
    nsxManagerSpecs = @(
      @{ name = "wld01-nsx01";
         networkDetailsSpec = @{ ipAddress = "10.16.11.45";
           dnsName = "wld01-nsx01.lab.local" } }
    )
    vipFqdn  = "wld01-nsx-vip.lab.local"
  }
}
$wldTask = New-VCFWorkloadDomain -json ($wldSpec | ConvertTo-Json -Depth 10)
do {
  Start-Sleep 60
  $wt = Get-VCFTask -id $wldTask.id
  "Workload domain build: $($wt.status)"
} while ($wt.status -eq "IN_PROGRESS")

VCF.PowerCLI alternative

The modern unified module uses verb-rich cmdlets such as Invoke-VcfGetHosts in place of Get-VCFHost. The response is less pre-parsed, so you filter it yourself, for example by workload domain id. PowerVCF remains the most concise option for the domain-creation flow above, which is why this guide leads with it.

08ESXi and Tintri NFS tuning

VCF mounts the datastore, but the Tintri best-practice tuning and the VAAI-NAS plugin are still your responsibility. Apply these consistently across every host. PowerCLI makes that a single loop.

Install the Tintri VAAI-NAS plugin

The VAAI-NAS plugin must be present on every ESXi host so clone and space operations offload to the VMstore. Without it, vSphere falls back to full host-driven copies, which are slower and consume host resources. Install the Tintri VIB, then reboot the host into the cluster.

PowerShell or ESXi: install the Tintri VAAI VIB

# Stage the Tintri VAAI-NAS offline bundle on a datastore, then per host:
esxcli software vib install -d /vmfs/volumes/ds-wld01-tintri-nfs/TintriVAAI.zip
# Confirm the plugin is registered after reboot:
esxcli storage nfs list
esxcli storage core plugin list | grep -i tintri

Apply the recommended advanced settings

Tintri publishes a small set of ESXi advanced settings for NFS environments. The headline one is raising the NFS volume limit, since a per-VM array can mount many datastores over time. Apply them across the cluster with PowerCLI.

PowerCLI: apply Tintri NFS advanced settings to every host

Connect-VIServer -Server wld01-vc01.lab.local
$settings = @{
  "NFS.MaxVolumes"          = 256   # raise NFS datastore ceiling
  "Net.TcpipHeapSize"       = 32    # MB, initial TCP/IP heap
  "Net.TcpipHeapMax"        = 1536  # MB, max TCP/IP heap
  "NFS.HeartbeatMaxFailures" = 10
  "NFS.HeartbeatFrequency"   = 12
  "NFS.HeartbeatTimeout"     = 5
}
$esx = Get-VMHost
foreach ($h in $esx) {
  foreach ($k in $settings.Keys) {
    $adv = Get-AdvancedSetting -Entity $h -Name $k
    if ($adv.Value -ne $settings[$k]) {
      Set-AdvancedSetting -AdvancedSetting $adv -Value $settings[$k] -Confirm:$false
      "$($h.Name): set $k = $($settings[$k])"
    }
  }
}

Storage I/O Control

Tintri manages quality of service per VM on the array. Storage I/O Control at the vSphere layer is generally not needed and can conflict with the array’s own scheduling, so most Tintri designs leave SIOC disabled on the Tintri datastore. Confirm against the current Tintri best-practice guide for your VMstore generation.

Confirm jumbo frames on the NFS VMkernel

PowerCLI: verify NFS VMkernel MTU is 9000

Get-VMHost | ForEach-Object {
  $vmk = Get-VMHostNetworkAdapter -VMHost $_ -VMKernel |
         Where-Object { $_.IP -like "10.16.13.*" }
  [PSCustomObject]@{
    Host = $_.Name
    VMK  = $vmk.Name
    IP   = $vmk.IP
    MTU  = $vmk.Mtu
    OK   = ($vmk.Mtu -eq 9000)
  }
} | Format-Table -AutoSize

09Validation with PowerShell and Python

An architect signs off only after validation. Verify the datastore is mounted and accelerated on every host, then confirm the domain is healthy through the SDDC Manager API. PowerShell handles the vSphere layer; Python is a clean way to script the REST layer and slot into a pipeline.

PowerShell: datastore and VAAI health across the cluster

PowerCLI: confirm mount and hardware acceleration

Get-VMHost | ForEach-Object {
  $h  = $_
  $ds = Get-Datastore -VMHost $h |
        Where-Object { $_.Name -like "*tintri-nfs*" }
  foreach ($d in $ds) {
    $accel = ($d.ExtensionData.Info.Nas) -ne $null
    [PSCustomObject]@{
      Host        = $h.Name
      Datastore   = $d.Name
      CapacityGB  = [math]::Round($d.CapacityGB,0)
      FreeGB      = [math]::Round($d.FreeSpaceGB,0)
      Accessible  = $d.ExtensionData.Summary.Accessible
    }
  }
} | Format-Table -AutoSize
# Per-host VAAI hardware acceleration status for the NFS datastore:
Get-VMHost | Get-EsxCli -V2 | ForEach-Object {
  $_.storage.nfs.list.Invoke()
}

Python: validate domain and storage through the SDDC Manager API

This script authenticates to SDDC Manager, lists workload domains, and confirms the principal datastore of each cluster. Drop it into a CI step to assert the environment after any change.

Python 3: SDDC Manager domain and storage validation

#!/usr/bin/env python3
"""Validate VCF workload domains and their NFS principal storage."""
import sys
import requests
from requests.packages.urllib3.exceptions import InsecureRequestWarning
requests.packages.urllib3.disable_warnings(InsecureRequestWarning)
SDDC  = "sddc-mgr.lab.local"
USER  = "administrator@vsphere.local"
PASS  = "ChangeMe"          # inject via env var or vault in practice
BASE  = f"https://{SDDC}/v1"
def get_token():
    r = requests.post(
        f"{BASE}/tokens",
        json={"username": USER, "password": PASS},
        verify=False, timeout=30,
    )
    r.raise_for_status()
    return r.json()["accessToken"]
def get(path, token):
    r = requests.get(
        f"{BASE}{path}",
        headers={"Authorization": f"Bearer {token}"},
        verify=False, timeout=30,
    )
    r.raise_for_status()
    return r.json()
def main():
    token = get_token()
    domains = get("/domains", token).get("elements", [])
    if not domains:
        print("No domains returned.")
        sys.exit(1)
    failures = 0
    for d in domains:
        name = d.get("name")
        dtype = d.get("type")
        status = d.get("status")
        print(f"\nDomain: {name}  type={dtype}  status={status}")
        if status != "ACTIVE":
            failures += 1
            print("  WARNING: domain is not ACTIVE")
        for c in d.get("clusters", []):
            cid = c["id"]
            cluster = get(f"/clusters/{cid}", token)
            ptype = cluster.get("primaryDatastoreType", "UNKNOWN")
            pname = cluster.get("primaryDatastoreName", "UNKNOWN")
            ok = "OK" if ptype.upper().startswith("NFS") else "CHECK"
            if ok != "OK":
                failures += 1
            print(f"  cluster={cluster.get('name')}  "
                  f"storage={ptype}:{pname}  [{ok}]")
    print(f"\nValidation complete. Issues found: {failures}")
    sys.exit(0 if failures == 0 else 2)
if __name__ == "__main__":
    main()

Field names

API field names such as primaryDatastoreType can vary slightly across VCF 9.0 and 9.1 point releases. If a field comes back empty, query one cluster object directly, inspect the JSON, and adjust the key. Treat the script as a template to confirm against your build, not a fixed contract.

10Design decisions, at a glance

This is the decision register an architect hands over with the build. It is the single most useful page for whoever operates the platform next.

11Pitfalls and lessons learned

• MTU mismatch is the number one NFS problem. If the VMstore data interface is left at the default 1500 while the hosts run 9000, you get silent fragmentation and bad latency. Prove jumbo frames with a do-not-fragment ping before deploying.
• Do not pre-mount the NFS datastore. Creating an NFS VMkernel or mounting the export on the hosts before the installer runs causes validation to fail. Let the installer create and mount.
• NFSv4.1 will not work as principal storage. If your array is set to v4.1, the domain creation will not accept it as principal. Use v3 for the principal export.
• DNS reverse lookup must succeed. The installer validates by PTR. Forward records alone are not enough.
• L3-separated NFS needs a static route. When the VMstore is on a routed subnet, add a static route so NFS egresses the correct VMkernel rather than the management gateway.
• Right-size the management domain. The full VCF 9 stack is resource-hungry; VCF Automation alone wants 24 vCPUs to boot. Undersized hosts cause the bring-up to stall.
• Image hosts to the exact BOM build. A near-miss ESXi version is rejected. Confirm the BOM in the release notes for your VCF build.

12Wrap-up and next steps

You now have a VCF 9 management domain and a VI workload domain, both backed by Tintri VMstore over NFSv3, built the way a Solutions Architect would build it: design first, document every decision, deploy deliberately, automate the repeatable parts, and validate before sign-off. The same pattern scales. Adding a second workload domain is the section 7 PowerShell flow again with new inputs, and the Python validation drops straight into a pipeline.

Natural follow-ups from here are setting up Tintri per-VM snapshots and replication for the workload domain, wiring VCF Operations dashboards for the NFS datastores, and building a Day 2 runbook for capacity growth on the VMstore. Each is a clean, self-contained next project, and each benefits from the same discipline: decide on paper, then automate.

A note on the commands

Cmdlet and API field names evolve across VCF 9 point releases. Always export your own installer JSON and inspect a live API response to confirm exact keys for your build. The scripts here are working templates, structured to be adapted rather than pasted blind.

VMwareBlogs.co.in

VMware Cloud Foundation 9 on Tintri NFS. Technical reference guide for lab and production design.