| Component | IP Address | FQDN | Role |
|---|---|---|---|
| Windows Depot Server | 192.168.1.160 | — | HTTPS offline depot (Python), port 8443 |
| VCF Installer | 192.168.1.240 | vcf-installer.lab.local | Initial bring-up appliance |
| SDDC Manager | 192.168.1.241 | sddc-manager.lab.local | Post-deployment lifecycle management |
| vCenter Server | 192.168.1.69 | vcenter.lab.local | vSphere management |
| DNS / NTP / AD | 192.168.1.230 | dc.lab.local | Infrastructure services |
| Gateway | 192.168.1.1 | — | Default gateway |
Note: The VCF Installer appliance (192.168.1.240) is used during initial bring-up. After deployment completes, SDDC Manager (192.168.1.241) takes over lifecycle management and depot operations. Both need depot access at different stages.
Metadata (required):
vcf-9.0.1.0-offline-depot-metadata.zip — Contains the PROD directory structure with manifest, product version catalog, vSAN HCL data, and compatibility dataAppliances and Binaries (VCF 9.0.1):
| File | Component | Size |
|---|---|---|
VCF-SDDC-Manager-Appliance-9.0.1.0.24962180.ova |
SDDC Manager | ~15 GB |
VMware-VCSA-all-9.0.1.0.24957454.iso |
vCenter Server | ~8 GB |
nsx-unified-appliance-9.0.1.0.24952114.ova |
NSX Manager | ~12 GB |
VCF-OPS-Lifecycle-Manager-Appliance-9.0.1.0.24960371.ova |
Aria Lifecycle | ~5 GB |
Operations-Appliance-9.0.1.0.24960351.ova |
VCF Operations | ~5 GB |
Operations-Cloud-Proxy-9.0.1.0.24960349.ova |
Operations Collector | ~3 GB |
O11N_VA-9.0.1.0.24923009.ova |
Orchestrator | ~3 GB |
vmsp-vcfa-combined-9.0.1.0.24965341.tar |
VCF Automation | ~15 GB |
Operations-Logs-Appliance-9.0.1.0.24960345.ova |
Operations for Logs | ~4 GB |
Operations-Logs-Appliance-9.0.1.0.24960345.pak |
Operations for Logs PAK | ~1 GB |
vidb-external-9.0.1.0.24941398.tar |
Identity Broker | ~2 GB |
VmwareCompatibilityData.json |
Compatibility Data | ~1 MB |
openssl req -x509 -newkey rsa:2048 `
-keyout "C:\VCF-Depot\server.key" `
-out "C:\VCF-Depot\server.crt" `
-days 365 -nodes `
-subj "/CN=192.168.1.160" `
-addext "subjectAltName=IP:192.168.1.160" -sha256
Alternatively, use the Python certificate generator:
cd C:\VCF-Depot
python generate_cert.py
This creates:
server.crt — the public certificate (will be imported into SDDC Manager)server.key — the private key (stays on the depot server)Two server scripts are available depending on your authentication needs:
Option A: FIPS-Compliant Server (No Authentication)
Script: C:\VCF-Depot\https_server_fips.py
cd C:\VCF-Depot
python https_server_fips.py
Option B: Authenticated Server (Basic Auth)
Script: C:\VCF-Depot\https_server.py
cd C:\VCF-Depot
python https_server.py
Which to use: For the VCF Installer bring-up phase, use the FIPS server (Option A) — the installer's BouncyCastle FIPS implementation is strict about cipher suites. For post-deployment depot operations through SDDC Manager, either option works. When using Option B, enter the username/password in the depot configuration UI.
netsh advfirewall firewall add rule name="VCF Depot 8443" dir=in action=allow protocol=tcp localport=8443
Open a browser and navigate to:
https://192.168.1.160:8443/
Accept the self-signed certificate warning. You should see a directory listing.
Extract the official metadata zip to create the base PROD structure:
Expand-Archive -Path "vcf-9.0.1.0-offline-depot-metadata.zip" -DestinationPath "C:\VCF-Depot\metadata-extract" -Force
Copy-Item "C:\VCF-Depot\metadata-extract\PROD\*" "C:\VCF-Depot\PROD\" -Recurse -Force
This creates the metadata structure that SDDC Manager queries first:
C:\VCF-Depot\PROD\
├── metadata\
│ ├── manifest\v1\
│ │ └── vcfManifest.json
│ └── productVersionCatalog\v1\
│ ├── productVersionCatalog.json
│ └── productVersionCatalog.sig
├── vsan\hcl\
│ ├── all.json
│ └── lastupdatedtime.json
└── COMP\SDDC_MANAGER_VCF\Compatibility\
└── VmwareCompatibilityData.json
New-Item -ItemType Directory -Path "C:\VCF-Depot\PROD\COMP\SDDC_MANAGER_VCF" -Force
New-Item -ItemType Directory -Path "C:\VCF-Depot\PROD\COMP\VCENTER" -Force
New-Item -ItemType Directory -Path "C:\VCF-Depot\PROD\COMP\NSX_T_MANAGER" -Force
New-Item -ItemType Directory -Path "C:\VCF-Depot\PROD\COMP\VRSLCM" -Force
New-Item -ItemType Directory -Path "C:\VCF-Depot\PROD\COMP\VROPS" -Force
New-Item -ItemType Directory -Path "C:\VCF-Depot\PROD\COMP\VCF_OPS_CLOUD_PROXY" -Force
New-Item -ItemType Directory -Path "C:\VCF-Depot\PROD\COMP\VRA" -Force
New-Item -ItemType Directory -Path "C:\VCF-Depot\PROD\COMP\VRO" -Force
New-Item -ItemType Directory -Path "C:\VCF-Depot\PROD\COMP\VRLI" -Force
New-Item -ItemType Directory -Path "C:\VCF-Depot\PROD\COMP\SDDC_MANAGER_VCF\lcm\productVersionCatalog" -Force
Copy each binary to its respective component directory:
| File | Destination Directory |
|---|---|
VCF-SDDC-Manager-Appliance-9.0.1.0.24962180.ova |
PROD\COMP\SDDC_MANAGER_VCF\ |
VMware-VCSA-all-9.0.1.0.24957454.iso |
PROD\COMP\VCENTER\ |
nsx-unified-appliance-9.0.1.0.24952114.ova |
PROD\COMP\NSX_T_MANAGER\ |
VCF-OPS-Lifecycle-Manager-Appliance-9.0.1.0.24960371.ova |
PROD\COMP\VRSLCM\ |
Operations-Appliance-9.0.1.0.24960351.ova |
PROD\COMP\VROPS\ |
Operations-Cloud-Proxy-9.0.1.0.24960349.ova |
PROD\COMP\VCF_OPS_CLOUD_PROXY\ |
O11N_VA-9.0.1.0.24923009.ova |
PROD\COMP\VRO\ |
vmsp-vcfa-combined-9.0.1.0.24965341.tar |
PROD\COMP\VRA\ |
Operations-Logs-Appliance-9.0.1.0.24960345.ova |
PROD\COMP\VRLI\ |
Operations-Logs-Appliance-9.0.1.0.24960345.pak |
PROD\COMP\VRLI\ |
vidb-external-9.0.1.0.24941398.tar |
PROD\COMP\VIDB\ |
productVersionCatalog.json |
PROD\COMP\SDDC_MANAGER_VCF\lcm\productVersionCatalog\ |
C:\VCF-Depot\
├── https_server.py # Authenticated HTTPS server
├── https_server_fips.py # FIPS-compliant HTTPS server
├── generate_cert.py # Certificate generator
├── server.crt # TLS certificate
├── server.key # TLS private key
├── start_depot.bat # Server startup script
└── PROD\
├── metadata\
│ ├── manifest\v1\
│ │ └── vcfManifest.json
│ └── productVersionCatalog\v1\
│ ├── productVersionCatalog.json
│ └── productVersionCatalog.sig
├── vsan\hcl\
│ ├── all.json
│ └── lastupdatedtime.json
└── COMP\
├── SDDC_MANAGER_VCF\
│ ├── VCF-SDDC-Manager-Appliance-9.0.1.0.24962180.ova
│ ├── Compatibility\
│ │ └── VmwareCompatibilityData.json
│ └── lcm\productVersionCatalog\
│ └── productVersionCatalog.json
├── VCENTER\
│ └── VMware-VCSA-all-9.0.1.0.24957454.iso
├── NSX_T_MANAGER\
│ └── nsx-unified-appliance-9.0.1.0.24952114.ova
├── VRSLCM\
│ └── VCF-OPS-Lifecycle-Manager-Appliance-9.0.1.0.24960371.ova
├── VROPS\
│ └── Operations-Appliance-9.0.1.0.24960351.ova
├── VCF_OPS_CLOUD_PROXY\
│ └── Operations-Cloud-Proxy-9.0.1.0.24960349.ova
├── VRA\
│ └── vmsp-vcfa-combined-9.0.1.0.24965341.tar
├── VRLI\
│ ├── Operations-Logs-Appliance-9.0.1.0.24960345.ova
│ └── Operations-Logs-Appliance-9.0.1.0.24960345.pak
├── VIDB\
│ └── vidb-external-9.0.1.0.24941398.tar
└── VRO\
└── O11N_VA-9.0.1.0.24923009.ova
Before configuring the depot, two prerequisites must be completed on the appliance.
The appliance must resolve its own hostname and vCenter's hostname. Without self-resolution, the LCM service fails with java.net.UnknownHostException.
# SSH into the appliance
ssh vcf@192.168.1.240 # VCF Installer during bring-up
# or
ssh vcf@192.168.1.241 # SDDC Manager post-deployment
su -
# Verify hostname resolves
hostname -f
# If it returns "Unknown host", add entries to /etc/hosts:
echo "192.168.1.240 vcf-installer.lab.local vcf-installer" >> /etc/hosts
echo "192.168.1.69 vcenter.lab.local vcenter" >> /etc/hosts
# Verify
hostname -f
python3 -c "import socket; print(socket.getaddrinfo('vcenter.lab.local', 443))"
The self-signed certificate from the depot server must be imported into the Java trust store before the depot can be configured.
Step 1: Extract the certificate from the running depot server:
echo | openssl s_client -connect 192.168.1.160:8443 2>/dev/null | openssl x509 > /tmp/depot.crt
cat /tmp/depot.crt # Verify it shows a PEM certificate
Step 2: Find and import into Java cacerts:
CACERTS=$(find /usr -name cacerts 2>/dev/null | head -1)
echo "Truststore: $CACERTS"
keytool -importcert -trustcacerts -alias offline-depot \
-file /tmp/depot.crt \
-keystore $CACERTS \
-storepass "changeit" -noprompt
Step 3: Import into commonsvcs trust store (if it exists):
COMMONSVCS="/etc/vmware/vcf/commonsvcs/temp_java_trusted_certificates.store"
if [ -f "$COMMONSVCS" ]; then
keytool -importcert -trustcacerts -alias offline-depot \
-file /tmp/depot.crt \
-keystore $COMMONSVCS \
-storepass "changeit" -noprompt
fi
Step 4: Restart services and verify:
systemctl restart commonsvcs lcm
# Wait 2-3 minutes
systemctl status commonsvcs lcm
Both services should show active (running).
Step 5: Verify import:
keytool -list -keystore $CACERTS -storepass changeit | grep offline-depot
Open a browser and navigate to:
https://192.168.1.240/ # VCF Installer during bring-up
# or
https://192.168.1.241/ # SDDC Manager post-deployment
In the depot configuration screen, enter:
| Field | Value (FIPS Server) | Value (Auth Server) |
|---|---|---|
| FQDN or IP Address | 192.168.1.160 |
192.168.1.160 |
| Port | 8443 |
8443 |
| Repository Path | /PROD |
/PROD |
| Username | (leave empty) | admin |
| Password | (leave empty) | admin |
Click Configure. SDDC Manager validates connectivity with a HEAD request to:
/PROD/metadata/productVersionCatalog/v1/productVersionCatalog.json
On success, the available VCF versions (e.g., 9.0.0.0, 9.0.1.0) appear in the UI.
Select VCF 9.0.1.0 and initiate the binary download. Monitor the depot server console window for request activity. All requests should return 200 status codes.
SDDC Manager downloads binaries to:
/nfs/vmware/vcf/nfs-mount/bundle/
Cause: SDDC Manager cannot validate the TLS connection to the depot server. The self-signed certificate is not in the trust store, or internal services are not running.
Fix:
/etc/hosts is configured correctly (Section 5.1)systemctl restart commonsvcs lcmsystemctl status commonsvcs lcmCause: The requested file does not exist at the expected path in the depot.
Fix: Check the HTTPS server console logs on the Windows machine. The log shows the exact path requested:
192.168.1.241 - "HEAD /PROD/COMP/VCENTER/VMware-VCSA-all-9.0.1.0.24957454.iso HTTP/1.1" 404 -
This tells you:
VCENTERVMware-VCSA-all-9.0.1.0.24957454.isoC:\VCF-Depot\PROD\COMP\VCENTER\VMware-VCSA-all-9.0.1.0.24957454.isoReference: Broadcom KB 413848
Cause: The productVersionCatalog.json was not extracted from the official metadata zip, or the LCM-specific copy is missing.
Fix:
productVersionCatalog.json to PROD\COMP\SDDC_MANAGER_VCF\lcm\productVersionCatalog\Cause: The SDDC Manager appliance cannot resolve its own hostname.
Fix: Add the hostname to /etc/hosts (Section 5.1). The entry must map the appliance IP to the FQDN and short hostname.
Cause: An internal SDDC Manager service is not running or has not fully started.
Fix:
systemctl restart commonsvcs lcm
# Wait 3-5 minutes
# Verify all ports are listening
ss -tlnp | grep -E "7100|7200|7300|7400|7500"
# All five ports should show LISTEN state
Cause: The certificate was already imported with the same alias.
Fix: This is safe to ignore. If you need to replace the certificate:
keytool -delete -alias offline-depot -keystore $CACERTS -storepass "changeit"
keytool -importcert -trustcacerts -alias offline-depot -file /tmp/depot.crt \
-keystore $CACERTS -storepass "changeit" -noprompt
Cause: ESXi hosts were booted before their hostname was configured. The auto-generated SSL certificate contains localhost.localdomain as the SAN instead of the actual FQDN.
Symptoms:
javax.net.ssl.SSLPeerUnverifiedException: Certificate for <esxi01.lab.local>
doesn't match any of the subject alternative names: [localhost.localdomain]
Fix: On each ESXi host, regenerate the SSL certificate:
ssh root@esxi01.lab.local
# Verify hostname is correct
esxcli system hostname get
# If wrong, set it
esxcli system hostname set --fqdn=esxi01.lab.local
# Regenerate certificates
mv /etc/vmware/ssl/rui.crt /etc/vmware/ssl/rui.crt.bak
mv /etc/vmware/ssl/rui.key /etc/vmware/ssl/rui.key.bak
/sbin/generate-certificates
# Restart ALL management services (hostd-only restart is insufficient)
services.sh restart
# Verify new certificate SAN
openssl x509 -in /etc/vmware/ssl/rui.crt -noout -text | grep -A2 "Subject Alternative"
Verify from SDDC Manager:
echo | openssl s_client -connect esxi01.lab.local:443 2>/dev/null | openssl x509 -noout -text | grep -A2 "Subject Alternative"
Repeat for all ESXi hosts before proceeding with VCF deployment.
Cause: services.sh restart did not fully bring all management services back up.
Fix: Access the ESXi host console (VMware Workstation console, press Alt+F1 for shell):
/etc/init.d/hostd start
services.sh restart
Symptoms: Bringup stuck at "Enable vSAN Policies." The domainmanager log shows:
VM vcenter is not compliant with the default storage policy
Waiting for 60 secs before checking storage compliance again
Cause: vSAN is actively rebuilding/resyncing data. The default policy requires FTT=1, which can't be satisfied until resync completes. The bringup checks every 60 seconds and proceeds automatically.
How to verify it is NOT hung:
tail -f /var/log/vmware/vcf/domainmanager/domainmanager.log | grep -E "compliant|Waiting|vsan"
# New lines every 60 seconds = working. Do NOT restart services.
How to check if it IS hung:
curl -s -k -u admin:<password> https://localhost/v1/sddcs | python3 -m json.tool | grep -i "status"
# Check all services running
systemctl status commonsvcs domainmanager lcm operationsmanager | grep -E "Active:|service"
# Verify all ports listening
ss -tlnp | grep -E "7100|7200|7300|7400|7500"
Resolution: Wait for vSAN resync to complete. In nested environments this can take 30-60+ minutes. Do NOT restart services.
Symptoms: VCF Operations deployment fails with:
failed due to time out after 20 MINUTES with exit value 137
Cause: The ovftool OVA deployment has a hardcoded 20-minute timeout in the domainmanager JAR. In nested environments with slow disk I/O, the upload can't complete in time. No external configuration exists to change this timeout.
Fix: Manual OVA Deployment with ovftool
Step 1: Discover vCenter inventory path:
ovftool --noSSLVerify "vi://administrator%40vsphere.local:<password>@vcenter.lab.local/"
# Lists datacenters — drill into each level:
ovftool --noSSLVerify "vi://administrator%40vsphere.local:<password>@vcenter.lab.local/<datacenter>/host/"
Step 2: Find the OVA:
find /nfs/vmware/vcf/nfs-mount/bundle/ -name "Operations-Appliance*.ova" 2>/dev/null
Step 3: Deploy manually (single-line command — no backslash continuation):
ovftool --acceptAllEulas --skipManifestCheck --noSSLVerify --diskMode=thin --powerOn --name=vrops-appliance --datastore=vcenter-cl01-ds-vsan01 --net:"Network 1"="vcenter-cl01-vds01-pg-vm-mgmt" --prop:vamitimezone=UTC --prop:root_password='<password>' "/nfs/vmware/vcf/nfs-mount/bundle/<bundle-id>/<bundle-id>/Operations-Appliance-9.0.1.0.24960351.ova" "vi://administrator%40vsphere.local:<url-encoded-password>@vcenter.lab.local/vcenter-dc01/host/vcenter-cl01/"
Important: Special characters in the password must be URL-encoded in the vi:// URL (e.g.,
!=%21). The@inadministrator@vsphere.localmust be encoded as%40. OVF network name "Network 1" must be mapped to the target portgroup using--net:syntax.
Symptoms: ovftool fails with "No version for VMODL calls" or curl to vCenter returns empty.
Fix: Add vCenter to /etc/hosts:
echo "192.168.1.69 vcenter.lab.local vcenter" >> /etc/hosts
python3 -c "import socket; s=socket.socket(); s.settimeout(5); s.connect(('vcenter.lab.local',443)); print('OPEN'); s.close()"
# Expected: OPEN
If vCenter services are down:
ssh root@vcenter.lab.local
service-control --status
service-control --start --all
Symptoms: Network failures between nested VMs, vMotion failures, or vSAN connectivity issues.
Cause: Nested ESXi VMs generate traffic with MAC addresses different from the parent VM's NIC.
Fix: Enable these security settings on ALL VDS portgroups (Management, vMotion, vSAN, VM-Mgmt):
The HTTPS server logs all requests to the console:
| Code | Meaning |
|---|---|
200 |
Successful request |
404 |
Missing file — check path and filename |
401 |
Authentication failure (auth-enabled server only) |
| File | Path |
|---|---|
| FIPS HTTPS Server | C:\VCF-Depot\https_server_fips.py |
| Auth HTTPS Server | C:\VCF-Depot\https_server.py |
| TLS Certificate | C:\VCF-Depot\server.crt |
| TLS Private Key | C:\VCF-Depot\server.key |
| Depot Root | C:\VCF-Depot\PROD\ |
| Startup Script | C:\VCF-Depot\start_depot.bat |
| File | Path |
|---|---|
| Java cacerts | /usr/lib/jvm/openjdk-java17-headless.x86_64/lib/security/cacerts |
| Commonsvcs Trust Store | /etc/vmware/vcf/commonsvcs/temp_java_trusted_certificates.store |
| Hosts File | /etc/hosts |
| Commonsvcs Logs | /var/log/vmware/vcf/commonsvcs/ |
| Domain Manager Logs | /var/log/vmware/vcf/domainmanager/ |
| LCM Logs | /var/log/vmware/vcf/lcm/ |
| OVFTool Logs | /var/log/vmware/vcf/domainmanager/vcf-ops-ovf-tool-*.log |
| Bundle Downloads | /nfs/vmware/vcf/nfs-mount/bundle/ |
PROD\ directory structurePROD\COMP\<COMPONENT>\ directories/etc/hosts — add appliance hostname and vCenter hostnameopenssl s_clientcommonsvcs and lcm services/PROD)Document Information
| Field | Value |
|---|---|
| Document Title | VCF 9.0.1 Offline Depot Handbook |
| Version | 2.0 (merged from Setup Guide + Handbook) |
| Last Updated | February 2026 |
| Environment | VMware Workstation 17.x Nested Lab |
| VCF Version | 9.0.1 |
This handbook is intended for lab and educational purposes. Always consult official VMware documentation for production deployments.
(c) 2026 Virtual Control LLC. All rights reserved.