VMware Cloud Director 10.6.x - The Definitive MSP Operations Guide

Enterprise & Service Provider Engineering | VMware Cloud Director

Before configuring anything, you need a clear picture of what changed in 10.6 versus previous releases. Several decisions you make during initial setup are permanent.

Release Baseline

Item	Detail
GA Release	June 27, 2024 - Build 24055813 (installer: 24055916)
10.6.0.1	September 6, 2024 - Build 24250702
10.6.1	January 31, 2025 - Build 24532678
10.6.1.1	May 30, 2025 - Build 24756346
10.6.1.2	December 5, 2025 - Build 25086345 (installer: 25088252)
Current Patch	VCD 10.6.1.2 (Dec 2025) - recommended production baseline
Supported NSX Version	NSX 4.1.x, 4.2.x (current: 4.2.3.3)
Supported vSphere	vSphere 8.0 U1, U2, U3 (current: 8.0 Update 3i)
Supported RabbitMQ	3.10.x, 3.11.x, 3.12.x
API Version	36.3 (latest in 10.6.x)

What Changed in 10.6

These are not incremental tweaks. Several of these changes alter how you architect a deployment from day one.

NSX Projects (Networking Tenancy): Introduced in 10.5.1, expanded significantly in 10.6. NSX Projects allow true multi-tenant networking isolation at the NSX level. The critical constraint: once you enable NSX Projects on a VDC, the network pool backing that VDC cannot be swapped. You also cannot change the networking tenancy model after the VDC is created. Make this decision before you provision anything.

Three-Tier Provider Model: VCD 10.6 significantly expanded the Sub-Provider role. You now have Provider, Sub-Provider, and Tenant as distinct tiers with independent resource delegation. Sub-Providers can create and manage their own tenants without requiring provider-level credentials. This is the right model for MSPs who wholesale to resellers.

AMQP Deprecated: AMQP is deprecated in 10.6. If you are upgrading from VCD 10.1 or earlier and still have AMQP configured, you must migrate to MQTT before or immediately after upgrade. AMQP broker settings cannot be deleted through the GUI - you need the API. This directly affects Zerto integrations.

DC Group Scaling: Data Center Groups now support up to 2000 VDCs per group, up from previous limits. If you are building large multi-datacenter MSP infrastructure, this opens architectural options that were not viable before.

Strict Mode IPAM: Sub-tenants can now be enforced to use only IPs within assigned static pools. This was not enforceable in prior releases and was a frequent source of IP overlap incidents in multi-tenant environments.

Mixed Tier-0/VRF Import: You can now import both a parent Tier-0 and its child VRFs simultaneously into VCD. This simplifies the routing import workflow considerably for MSPs running VRF-based tenant segmentation.

Certificate Library: CA-signed certificates are now managed through the Certificate Library (introduced in 10.5.1, expanded in 10.6). If you are restoring a VCD deployment from backup and have CA-signed certs, the restore will fail if there is a password mismatch between the cert password at backup time and restore time. There is a specific procedure for this - covered in the certificates section.

VMware publishes cell sizing recommendations but they are conservative baselines. MSP deployments that handle significant tenant load or are running Veeam + Zerto integration alongside VCD need to size up from those baselines.

Cell VM Specifications

Deployment Size	vCPU	RAM	OS Disk	Transfer Dir	Notes
Small (<100 tenants)	8	16 GB	60 GB	500 GB+	Single cell acceptable
Medium (100-500 tenants)	16	32 GB	60 GB	1 TB+	2+ cells recommended
Large (500+ tenants)	32	64 GB	60 GB	2 TB+	4+ cells, dedicated DB

Disk Layout Recommendations

Mount Point	Minimum Size	Notes
/	60 GB	OS and VCD binaries only. Do not let logs or transfer data land here.
/opt/vmware/vcloud-director/data/transfer	500 GB+	Separate volume. This is where backup files, uploads, catalog items stage. Size to your workload.
/var/log	50 GB+	Separate volume strongly recommended. Logging volume increases significantly after upgrade to 10.6.

Networking Requirements

Connection	Port	Direction	Notes
VCD UI/API (HTTPS)	443	Inbound to cell	Load balanced across cells
VCD Console Proxy	8443	Inbound to cell	VM remote console access
Cell-to-cell	5480	Between cells	Management and heartbeat
VCD to vCenter	443	Outbound	vSphere API
VCD to NSX Manager	443	Outbound	NSX API
VCD to RabbitMQ	5671	Outbound	AMQP/MQTT (TLS)
VCD database (PostgreSQL)	5432	Outbound	External DB deployments

Database Sizing

The embedded PostgreSQL instance is fine for small deployments. For production MSP environments with 100+ tenants, run an external PostgreSQL instance. This lets you manage backups, replication, and disk growth independently of the VCD cell VMs. PostgreSQL 14 or 15 is the tested range for VCD 10.6.x. Allocate at minimum 4 vCPU and 8 GB RAM for the database VM, with fast storage - latency to the database directly impacts VCD API response times.

NSX configuration is where most MSP deployments go sideways during initial setup. The decisions made here are largely permanent.

NSX Projects (Networking Tenancy) - What You Need to Know Before You Start

NSX Projects allow VCD to create tenant-scoped NSX constructs - Tier-1 gateways, segments, and security policies - within a namespace isolated from the provider infrastructure. This is the right model for MSP environments because it prevents tenant networking from polluting the provider NSX space.

NSX Projects Configuration

Mixed T0/VRF Import

VCD 10.6 now supports importing both a parent Tier-0 and its child VRFs simultaneously. In prior releases you had to choose one or the other as your uplink model. The mixed import enables MSPs to share a physical Tier-0 infrastructure across tenants while using VRFs for routing isolation - a common design in MPLS-adjacent environments.

DC Group Scaling

VCD 10.6 raised the Data Center Group limit to 2000 VDCs per group. For MSPs running stretched DRaaS architectures across multiple regions, this is a meaningful change. A DC Group in VCD is the construct that enables cross-site networking - stretched segments, centralized gateway configuration, and cross-VDC routing. With the 2000-VDC limit, you can now consolidate what previously required multiple DC Groups into a single management plane.

NSX Geneve Overlay Architecture

NSX TEP VLAN Design for VCD Environments

The Tunnel Endpoint (TEP) VLAN is the underlay network that carries all Geneve-encapsulated overlay traffic between ESXi hosts and NSX Edge nodes. Getting this wrong causes intermittent VM-to-VM connectivity failures that are extremely difficult to diagnose after the fact. Design it before you rack anything.

Layer	Minimum MTU	Recommended MTU	Where Configured
Physical switches (TEP VLAN ports)	1600	1700	Switch interface config
ESXi vmnic (physical uplinks)	1600	1700	vSwitch uplink MTU
NSX Global TEP MTU	1600	1700	NSX: System > Fabric > Settings > Global Fabric Settings
NSX Uplink Profile MTU	1600	1700	NSX: System > Profiles > Uplink Profiles
VDS MTU (if using VDS)	1600	1700	vCenter: Distributed Switch > Edit > Advanced
NSX Gateway Interface MTU	1400	1500	NSX: Global Networking Config - must be 200 below TEP MTU
Tenant VM NIC MTU	1500	1500	Guest OS - no change required

Edge Uplink Profile Design

The NSX Edge uplink profile defines how Edge nodes connect to the physical network. In VCD environments this matters because Edge nodes carry all tenant north-south traffic. A badly designed uplink profile causes asymmetric routing, MTU mismatches, or LACP negotiation failures that make every tenant's internet connectivity unreliable.

Setting	Recommended Value	Why
MTU	1700	Matches Global TEP MTU. Must be consistent.
Teaming policy	Load Balance Source MAC (Failover Order for bare-metal edges)	Source MAC teaming works without LACP on the physical switch. Use Failover Order for bare-metal Edge appliances where LACP is not available.
Transport VLAN	Dedicated VLAN (e.g. VLAN 100) separate from VM traffic	TEP traffic must be isolated from tenant VM VLANs. Mixing them causes broadcast domain issues and complicates troubleshooting.
Named teaming override	Match your physical switch bond/LAG config	If physical switches use LACP, use LACP Active/Passive. If using static LAG, use Load Balance Source Port ID.

Geneve Tunnel Troubleshooting

When overlay connectivity fails between VMs on different hosts, the diagnostic sequence is the same every time. Work the layers from bottom up: physical MTU, TEP reachability, tunnel state, then logical forwarding.

IP Spaces replaced the legacy External Networks model for managing public IP allocations in VCD. If you are still on legacy External Networks, plan your migration - IP Spaces are the only supported model going forward for new deployments.

IP Space Architecture for MSPs

The correct model for a multi-tenant MSP: one Public IP Space containing your provider IP block, then IP Space Uplinks assigned to each Org VDC Edge Gateway. Tenants request IPs from their assigned uplink quota. The provider controls how many IPs each tenant can consume and can enforce that tenants cannot use IPs outside their assigned static pools using Strict Mode IPAM.

Strict Mode IPAM

Strict Mode IPAM is the setting that prevents sub-tenants from allocating IPs outside the static pools you have assigned to them. Without Strict Mode, a tenant with API access can request IPs from the broader IP Space range, not just their allocation. Enable this on every sub-provider and tenant account unless you have a deliberate reason not to.

Getting the allocation model wrong is the most common misconfiguration in VCD deployments. Each model behaves differently under load and the differences matter for MSP billing accuracy.

Model	How It Works	Best For	Gotcha
Allocation Pool	Fixed CPU/RAM reservation at VDC level. Tenants consume from the fixed pool.	Predictable dedicated tenants, SLA-backed compute. Enterprise departments with defined budgets.	Over-reservation possible. Size carefully.
Reservation Pool	All resources guaranteed and reserved immediately on creation.	High-performance workloads, latency-sensitive apps, compliance environments requiring guaranteed compute	Expensive in terms of provider resource consumption. Rarely the right default.
Pay-As-You-Go	No reservation. VMs consume what they use. Provider cluster resources are shared.	Dev/test, variable workloads, non-critical internal workloads	No hard isolation. Noisy neighbors are possible.
Flex	Hybrid. Guaranteed minimum + elastic burst. Memory overhead optional.	Best default for most use cases - MSP tenants and enterprise business units. Best balance of isolation and efficiency.	See below - specific configuration requirement in 10.6.

If you are running Zerto, read this section before anything else. Zerto depends on RabbitMQ for VCD event delivery. Get this wrong and Zerto goes silent with no obvious error.

The AMQP Deprecation Timeline

MQTT replaced AMQP as the inter-cell and external messaging protocol starting with VCD 10.1. AMQP remained available as a compatibility option through 10.5. In 10.6, AMQP is officially deprecated. Fresh installs of 10.6 configure MQTT only. Upgrades from environments that had AMQP configured leave the old broker settings in the database.

The immediate impact: Zerto historically used AMQP/RabbitMQ for its VCD integration. The AMQP deprecation is a compatibility concern you need to verify with your Zerto version before upgrading VCD.

RabbitMQ Version Requirements for VCD 10.6

RabbitMQ Version	VCD 10.6 Support
3.10.x	Supported
3.11.x	Supported
3.12.x	Supported
3.9.x and below	Not supported with VCD 10.6
3.13.x+	Verify with current Broadcom interoperability matrix

Cleaning Up Stale AMQP Configuration

If you are on VCD 10.5.1+ and still have AMQP broker settings configured (because you upgraded from an older version), remove them via the API before they cause problems:

VCD 10.6 uses the Certificate Library as the central management plane for all CA-signed certificates. This changes the restore and renewal workflow.

Certificate Library Overview

The Certificate Library (available since 10.5.1) stores CA-signed certificates as named objects that can be referenced by VCD cells, Edge Gateways, and other components. This is a significant improvement over the old model where certificates were tied directly to individual component configurations. Renewals and replacements now happen in one place.

Certificate Renewal Process

Veeam Cloud Connect with VCD is well-documented but there are specific configuration points that cause problems in production that the official docs do not emphasize enough.

Architecture Overview

Veeam Cloud Connect + VCD Architecture

Veeam Cloud Connect integrates with VCD at the Organization level. The service provider does not create new vSphere objects for VCD tenants. Instead, the SP pre-creates Organization VDCs in VCD with the appropriate resources, then exposes those to Veeam tenants. The tenant accesses the cloud host using their Organization Administrator credentials from VCD.

Component	Role	Notes
Veeam Backup Server (SP)	Cloud Connect gateway, job orchestration	Connects to VCD via VCD API
Cloud Gateway	Data path for backup traffic	Separate from VCD; handles Veeam protocol
VCD Organization	Tenant namespace in VCD	One org per Veeam Cloud Director tenant account
Organization VDC	Compute resources for replicas	Pre-created by SP in VCD before assigning to tenant
VCD Org Admin	Credential used by tenant to connect	Must have Org Administrator rights in VCD org

Creating a Cloud Director Tenant Account in Veeam

Veeam Self-Service Backup Portal for VCD

Veeam Backup Enterprise Manager provides a Self-Service Backup Portal that VCD tenants can access using their native VCD credentials. The SP does not need to manage separate Veeam user accounts - authentication passes through VCD's identity mechanism. The SP configures job templates, repository quotas, and scheduling restrictions at the Organization level in Enterprise Manager.

Key controls the SP can enforce per Organization: backup job template (forces all tenant jobs to use a specific template), repository destination, quota limits, scheduling frequency limits (prevent jobs from running too often), and full scheduling lockout (where the SP controls the schedule, not the tenant).

Veeam Plugin Management in VCD

Veeam ships a VCD UI plugin with each VBR release. This plugin adds Veeam backup controls into the VCD tenant portal. When you upgrade VBR, you must manually update the plugin in VCD - it does not auto-update. Running a mismatched plugin version against a newer VBR causes API errors and broken backup portal functionality for tenants.

Finding the Plugin on the VBR ISO

Removing the Old Plugin

Uploading and Publishing the New Plugin

VBR Version Change	Plugin Action Required	Where to Get Plugin
12.x to 12.y (minor update)	Delete old, upload new	New VBR ISO or installation directory
12.x to 13.0.1 (major upgrade)	Delete old, upload new - mandatory	VBR 13.0.1 ISO
13.0.1 Patch update	Check KB4738 - patch notes state if plugin changed	KB4738 documents each patch's scope

CDP for VCD Replicas

Continuous Data Protection is supported for VCD replica targets. CDP requires vSphere 7.0 U1+ on the source and VCD 10.3+ with NSX on the target. For VCD 10.6 deployments, CDP is available if the underlying vSphere meets the requirements. Configure CDP replication jobs in Veeam and target the Organization VDC as you would for a standard replication job - the CDP policy is set at the job level, not the infrastructure level.

Veeam + VCD Compatibility Matrix

Veeam VBR Version	VCD 10.6 Support	Notes
Veeam VBR v13	Full support	Recommended version for VCD 10.6 deployments
Veeam VBR v12.x	Support per KB4488	VCD 10.1-10.6 listed as supported; verify patch level
Veeam VBR v11 and below	Not recommended	VCD 10.6 API changes; use v12 or v13

Zerto in a VCD environment operates through the Zerto Cloud Manager (ZCM). ZCM is the management layer that sits above individual ZVM (Zerto Virtual Manager) instances at each site and provides the multi-tenant VCD-aware control plane.

Architecture

In a VCD-integrated Zerto deployment:

The Zerto Cloud Manager communicates with VCD to discover organizations and VDCs. Individual ZVMs are deployed at each protected vSphere site. The Zerto Self-Service Portal (ZSSP) integrates with CSP portals and allows tenants to manage their own VPGs within their VCD Organization scope. VPG failover targets are pre-configured to use Organization VDCs in VCD as recovery destinations.

VCD 10.6 and AMQP - The Critical Dependency

VCD 10.6.1.1 RabbitMQ Event Flooding Bug - Impact on Zerto

RabbitMQ Requirements for Zerto + VCD

Component	Requirement
RabbitMQ version	3.10.x, 3.11.x, or 3.12.x for VCD 10.6
Erlang/OTP	Must be compatible with selected RabbitMQ version
Zerto queue name	systemExchange - must exist; not auto-created on new cluster
Queue durability	Durable=true; all other settings false
TLS	Port 5671 (TLS-encrypted AMQP). Configure TLS on RabbitMQ listener.
vHost	Default vHost (/) unless customized in VCD AMQP configuration

Zerto Cloud Manager VCD Configuration

Known Zerto Limitations with VCD

Limitation	Detail
vApp network replication	Zerto does not replicate vApp network settings (NAT, firewall, DHCP). Post-failover scripts required to restore these settings.
vApp network fence mode	Fence mode must not be enabled when performing failover, test failover, or move operations.
Protected machine scope	VMs are protected as a VCD vApp in the recovery VCD. Individual VMs from a vApp can still be independently protected.
Metadata replication	vCD entity metadata is replicated. Network settings within the vApp (NAT/FW/DHCP) are not.
Disk resize during replication	If a protected VM disk is resized, the recovery disk cannot be automatically resized - manual intervention required post-failover.

Zerto Self-Service Portal Integration

ZSSP is the tenant-facing interface for VCD-integrated Zerto deployments. Tenants log in using their VCD Organization credentials. ZSSP shows them only the VPGs and recovery assets within their VCD Organization scope. Configure the ZSSP-to-CSP portal integration to present Zerto DRaaS as a self-service offering within your existing MSP customer portal.

Every significant known issue across the 10.6.x release line, tagged by the version in which it was introduced and the version in which it was resolved (if fixed). Use this as your upgrade decision matrix. If a bug affects your environment and is fixed in a later release, that is your upgrade path justification.

Infrastructure and Platform

Logging

Networking and Edge Gateway

Virtual Machine Operations

Flex VDC and Resource Pool

Storage and Catalog

IP Management and Reservations

Authentication, Certificates, and Identity

TKG and Kubernetes (Enterprise Deployments)

RabbitMQ and External Integrations

Bug Resolution Summary by Version

Version	Key Bugs Fixed	Recommendation
10.6.0	GA - multiple bugs present from launch	Never deploy as target. Go to 10.6.0.1 minimum.
10.6.0.1	RPM install failure, catalog metadata sync	Acceptable minimum baseline only if 10.6.1 is not yet tested in your environment.
10.6.1	VM import retry, snapshot revert on vSAN, 100-rule firewall limit, VM sizing policy fail	Significant improvements. Upgrade from 10.6.0.1.
10.6.1.1	Rate limiting on NSX Tenancy VDCs, stateless firewall on VDC groups, IP expiry bug, CPU spikes post-upgrade	Good release but introduces the Flex elasticity / vrp_rp deactivation bug. Upgrade to 10.6.1.2.
10.6.1.2	Flex elasticity deactivation (fixed), VM lease expiry (fixed), catalog slash bug (fixed), TKG CSE fix, storage policy change. Relocate task timeout increased from 5 to 10 minutes.	Current recommended production target. RabbitMQ event flooding remains open. Verify post-upgrade event flow to RabbitMQ.

VCD Log Locations

Log Path	Content	Growth Rate in 10.6
/opt/vmware/vcloud-director/logs/cell.log	Primary VCD service log	High - rotate aggressively
/opt/vmware/vcloud-director/logs/vcloud-container-debug.log	Debug output	Very high if debug enabled
/opt/vmware/vcloud-director/data/transfer/backups	VCD configuration backups (10.6+)	Grows with each scheduled backup
/var/log/vmware	VMware platform logs	Moderate; increased in 10.6

Log Rotation Configuration

VCD 10.6 increased the default logging verbosity compared to 10.5. If you are not running centralized log shipping (Syslog to your SIEM or log aggregator), you will fill local disk. Configure log rotation explicitly:

Event Table Maintenance

The VCD event table in PostgreSQL grows indefinitely without active maintenance. In VCD 10.6.1.1, a large event table actively causes the RabbitMQ integration to fail. Beyond that specific bug, an oversized event table degrades API performance across the board. Implement a scheduled maintenance task to archive or purge events older than your retention requirement.

Monitoring Checklist

The following items should be in your monitoring stack for every VCD 10.6 deployment:

Cell service health: poll https://vcd-cell/api/sessions - a response indicates the API is alive. VCD cell disk usage: root, transfer, and log volumes at 75% and 90% thresholds. RabbitMQ connectivity: VCD Admin extensibility check, and independently verify event flow by monitoring the systemExchange queue message rate. Database connection pool: VCD API latency increases significantly when the PostgreSQL connection pool is saturated. Certificate expiry: set alerts at 60 and 30 days before expiry for all certs in the Certificate Library. VCD backup file age: verify the backup file in /opt/vmware/vcloud-director/data/transfer/backups is being updated on schedule.

Monitoring Wired to Real Tools

The checklist in Section 12 tells you what to monitor. Here is how to wire it up in the monitoring tools MSPs actually use.

Zabbix

PRTG

Prometheus / Grafana (for MSPs running modern observability stacks)

Certificate Expiry Monitoring (All Platforms)

Run this checklist against every new VCD 10.6 deployment before going live - MSP and enterprise alike. It covers the permanent decisions and the most common misconfiguration points. Some items are SP-specific (multi-tenant IP isolation, sub-provider escalation paths) - mark them N/A if they do not apply to your deployment model.

Pre-Deployment Planning

Item	Verified	Notes
Network pool architecture documented before VDC creation	[ ]	Cannot change after VDC creation
NSX Projects topology designed and created in NSX Manager	[ ]	One project per tenant tier or shared per decision
RabbitMQ version confirmed 3.10.x-3.12.x	[ ]	Required for VCD 10.6 compatibility
Zerto version confirmed compatible with VCD 10.6 and MQTT	[ ]	Verify with Zerto interoperability matrix at time of deployment
Veeam version confirmed - VBR v12+ recommended	[ ]	v13 preferred for VCD 10.6
Disk layout planned: separate volumes for transfer, logs, OS	[ ]	Do not put transfer data on root
IP Space architecture documented	[ ]	Which tenants get which subnets
Tenancy model decision documented (Provider / Sub-Provider / Tenant for SP, or flat Org model for enterprise)	[ ]	Document escalation paths for sub-providers if applicable
Certificate password policy documented for Certificate Library	[ ]	Required for restore operations

Post-Deployment Verification

Item	Verified	Notes
vmware-vcd service running on all cells	[ ]	Check systemctl status vmware-vcd
VCD API responding on load balancer VIP	[ ]	GET /api/sessions returns 200
AMQP stale settings removed (if upgrade from pre-10.1)	[ ]	Via API - not available in UI
RabbitMQ event flow confirmed from VCD	[ ]	Monitor systemExchange queue activity
Strict Mode IPAM enabled on all sub-provider/tenant accounts	[ ]	Prevents IP range escape
Flex VDC guaranteed resources set to non-zero value	[ ]	Avoids over-provisioning calculation bug
Log rotation configured on all cells	[ ]	Verify with logrotate -d
Disk monitoring alerts active for root, transfer, log volumes	[ ]	75% and 90% thresholds minimum
Veeam Cloud Director tenant accounts created and tested	[ ]	Test backup and restore with a test VM
Zerto Cloud Manager connected and VPG test failover performed	[ ]	Do not accept production without a test failover
Certificate expiry alerts configured	[ ]	30 and 60 day advance notice
VCD configuration backup running and verified	[ ]	Confirm backup file age in transfer/backups
IP reservation expiry dates adjusted (+1 day buffer)	[ ]	Known date calculation bug in 10.6
Failed vApp template cleanup process documented	[ ]	Operational runbook entry

The embedded vPostgres database in the VCD appliance is not a black box you leave alone. It requires active maintenance, and several of the bugs documented in Section 11 require direct database access to remediate. What follows covers connecting locally and remotely, safely cleaning up the tables that cause performance degradation and the RabbitMQ event flooding bug, and the autovacuum settings that prevent TOAST bloat from filling your disk.

Connecting Locally on the Primary Cell

The embedded database is named vcloud. Connect as the postgres superuser from the primary cell shell:

Once connected, verify you are in the right database and check table sizes before doing anything else:

Connecting Remotely with PgAdmin

The embedded PostgreSQL listens only on localhost by default. Remote access requires three changes: a pg_hba.d drop-in rule, a firewall rule for port 5432, and confirming listen_addresses. The VCD appliance uses a drop-in directory model - do not edit pg_hba.conf directly, use the drop-in directory.

Audit Trail and Event Table Cleanup

The audit_trail table is the primary driver of database bloat in active VCD deployments. The open RabbitMQ event flooding bug in VCD 10.6.x is directly linked to an oversized event table - keeping this table clean is the primary operational workaround until Broadcom ships a fix. This is the supported cleanup procedure from Broadcom KB 320412.

Configure Automatic Retention to Prevent Recurrence

After cleaning up, configure VCD to automatically enforce retention limits. Run these on any one cell - the settings propagate to all cells via the database:

TOAST Bloat and Autovacuum Configuration

The TOAST data size increase in PROPERTY_MAP and PROPERTY_MAP_STATUS in 10.6 requires autovacuum to be properly tuned. Default PostgreSQL autovacuum settings are too conservative for a busy VCD instance. The following settings belong in /var/vmware/vpostgres/current/pgdata/postgresql.conf:

After editing, reload without a full PostgreSQL restart:

For the activity_parameters table specifically, which is a frequent bloat source, run a manual vacuum if autovacuum has not caught up:

Database Monitoring Queries

Run these periodically or set them up as scheduled monitoring tasks in your RMM tooling:

vPostgres Service Management

Operation	Command	Notes
Check service status	systemctl status vpostgres	Run on primary cell
Start vPostgres	systemctl start vpostgres	Start before vmware-vcd
Stop vPostgres	systemctl stop vpostgres	Stop after vmware-vcd is down
Check replication status	sudo -i -u postgres psql -c "SELECT * FROM pg_stat_replication;"	Run on primary - shows standby lag
Check standby lag	sudo -i -u postgres psql -c "SELECT now()-pg_last_xact_replay_timestamp() AS lag;"	Run on standby cell
Find data directory	sudo -i -u postgres psql -c "SHOW data_directory;"	Confirm before disk operations
Find log directory	ls /var/vmware/vpostgres/current/pgdata/log/	PostgreSQL logs here

VCD is a Java application. When something goes wrong - a cell fails to start, the API stops responding, tasks hang - the first place you go is the logs. Most engineers skim these and give up too fast. Read on for how to read them quickly and match error patterns to known causes.

Log File Map

Log File	What It Contains	When to Use It
cell.log	Cell startup sequence. Reports subsystem init percentage and status. Rewrites on every service restart.	First stop when a cell won't start or the UI is unreachable. Watch tail -f cell.log during startup.
cell-runtime.log	Runtime Java exceptions, task failures, internal service errors, timeout errors.	Cell started but something isn't working - a task is stuck, an API call is failing, the 5-minute restart loop.
vcloud-container-debug.log	Internal inter-service communications, detailed debug output.	Deep troubleshooting only. Very high volume. Look here when cell.log and cell-runtime.log don't explain the failure.
vcloud-container-info.log	Warnings and errors from the VCD container. Less verbose than debug.	Good secondary source. Auto-import failures log here.
vmware-vcd-watchdog.log	Watchdog service attempts to restart vmware-vcd if it hangs or stops.	Cell is restarting repeatedly - confirms the watchdog is triggering and shows restart frequency.
networking.log	NSX and network provisioning operations.	Edge gateway creation failures, NSX API timeouts, network pool exhaustion.
vclistener.log	vCenter event listener. All VCListener traffic from vSphere.	PostgreSQL TOAST spike investigation. High event volume correlation.

Reading cell.log During Startup

A healthy startup in cell.log looks like this - each percentage step represents a subsystem coming up:

If it never reaches 100%, look at what percentage it stopped at:

Stuck At	Failing Subsystem	Most Likely Cause
9%	common.core	Database connection failure. Check PostgreSQL is running, check JDBC URL in global.properties, check pg_hba.conf allows the connection.
WAITING (any %)	Any	A dependency subsystem has not started. Look at vcloud-container-debug.log for what the stalled subsystem is waiting on.
Startup fails immediately	global.properties	File not found or permissions wrong. Compare ownership and chmod to a working cell. The vcloud user needs read access.
Console proxy error	consoleproxy	IP address in the console proxy config does not exist on the cell's network interface. Check the console proxy IP setting in the VCD admin portal against the cell's actual IP.

Common Java Exceptions and What They Mean

Useful Log Grep Patterns

Enabling Debug Logging Temporarily

Default log level is INFO. For active troubleshooting, you can bump specific components to DEBUG without restarting the VCD service using the log4j configuration. Add or modify entries in /opt/vmware/vcloud-director/etc/log4j.properties on the cell where the problem is occurring:

Changes to log4j.properties take effect within 60 seconds without a service restart. Remove debug entries after troubleshooting to avoid disk fill from verbose output.

This is one of the most common operational pain points in VCD environments. VMs end up in states VCD cannot reconcile - deleted in vCenter but still showing in VCD, stuck in UNKNOWN power state, stranded in the StrandedItems folder, or orphaned in the database after a failed import. Each scenario has a different resolution path.

Scenario 1: VM Shows as UNKNOWN - Deleted in vCenter but Still in VCD

This is the most common scenario. Someone deleted a VM directly from vCenter without going through VCD. The VCD database still has the record. The VM shows as UNKNOWN and all operations on it are disabled.

Scenario 2: Mass UNKNOWN State After Crash or Storage Failure

After an unclean shutdown - storage failure, power outage, host crash - multiple or all VMs in VCD may show UNKNOWN. The VMs are fine in vCenter. VCD cannot reconcile their states because the inventory cache tables are stale or corrupted.

Scenario 3: VM in Inconsistent Power State (VCD Says Off, vCenter Says On)

This happens when a VM's power state is changed directly in vCenter outside of VCD's control - HA restart, manual power-on, Veeam instant recovery, Zerto test failover. VCD receives the state change event but the sequencing leaves VCD expecting one state while vCenter has another.

Scenario 4: VM Shows in VCD But Not Discovered (Invisible to VCD)

A VM exists in vCenter in a managed resource pool but VCD has not discovered or adopted it. This happens after a restore, a vMotion from an unmanaged pool, or when the auto-discovery mechanism skipped the VM for a specific reason.

Scenario 5: Restored VM Not Discovered (cloud.uuid Collision)

You restored a VM from backup (Veeam, Zerto test failover, snapshot revert) into the same resource pool. VCD does not discover it even though the VM is visible in vCenter. The cause: the restored VM has the same cloud.uuid as the original. VCD sees what it thinks are two copies of the same VM and will not import the restored copy.

Scenario 6: VM Appears in VCD, vApp is Stuck in "Busy" State, No Operations Available

The vApp is in a permanent Busy state. No power operations, no delete, nothing. This typically happens after an interrupted vApp creation, a VCD crash mid-operation, or a failed network provisioning step that left the vApp in a transitional state with no way to proceed or roll back through the UI.

Scenario 7: VMs Deleted from VCD, Now in StrandedItems Folder in vCenter

When you delete an auto-discovered VM from VCD (not a VCD-provisioned VM), VCD moves the VM to a StrandedItems folder in vCenter and renames it with a suffix like vcentervm-1 (vm-uuid). The VM is not deleted from vCenter - it is just moved and tagged as stranded.

Removing a VM from VCD Management (Deliberate Extraction)

Sometimes you legitimately need to pull a VM out of VCD management - moving to a different CMP, migrating cross-vCenter, or rebuilding the VCD environment without destroying the VM. This is the supported procedure from Broadcom KB 320484:

Auto-Discovery Configuration Reference

CMT Setting	Default	Description
managed-vapp.discovery.retry-delay-sec	3600 (60 min)	How long VCD waits before retrying a failed auto-import. Set lower during troubleshooting.
Discovery cycle frequency	Every 3 minutes	Not configurable. VCD polls vCenter every 3 minutes for new VMs in managed resource pools.

The failure modes in this section span VCD and the components around it - the console proxy, NTP, certificate trust chains, vCenter connectivity, Veeam integration specifics, Terraform, CSE Kubernetes, and media uploads. Most of these are not bugs in the 10.6 release notes but operational patterns that hit MSP and enterprise environments consistently.

Console Access and VMRC

NTP - The Silent Infrastructure Killer

Symptom	Root Cause
SAML authentication failures / "token expired" errors	SAML assertions have short validity windows. Even 30 seconds of drift causes them to fail validation.
API token validation failures	VCD API tokens are time-bounded. Drift causes token rejection before the configured TTL.
PostgreSQL HA replication breaks	The embedded PostgreSQL replication heartbeat relies on time synchronization. Drift causes the standby to fall out of sync.
VMRC console instant disconnect	MKS ticket timestamp validation fails at ESXi host if clocks are out of sync.
Zerto VPG state inconsistency	Zerto journal timestamps drift relative to VCD event timestamps, causing VPG sync issues.
Veeam backup job failures with "timestamp" errors	Veeam's authentication to VCD uses time-sensitive tokens that fail when clocks are skewed.
SSL certificate "not yet valid" errors	A clock that is behind may see a certificate as not yet valid even though it is deployed correctly.

Certificate Trust and Chain Issues

vCenter and Storage Integration

Veeam Integration - Additional Specifics

CSE Kubernetes

Terraform and Infrastructure as Code

Stuck Media Uploads

These are the issues that experienced VCD engineers hit in production but rarely find documented in one place. Some are architectural constraints you work around, some are bugs with specific remediation steps, and some are operational patterns that only emerge at MSP scale.

Veeam + VCD Version Lockstep - The Upgrade Trap

VCD Version	Minimum Veeam VBR Required	Notes
VCD 10.5.x	VBR 12.1+	VBR 12.1.2 was the first version with VCD 10.5 support
VCD 10.6.x	VBR 12.2+ (build 12.2.0.334, August 2024)	VBR 12.1.2 does not support VCD 10.6. VBR 12.2 added the API support for VCD 10.6 methodologies.

Veeam CDP I/O Filter and ESXi Certificate Sync

Veeam Self-Service Portal - Tenant API Authentication Gap

NSX-T Geneve MTU - The Silent Drop Problem

The Elastic pVDC Slingshot Bug (10.4.x)

Appliance eth1 IP Change - Why You Cannot Just Change It

The Quartz Scheduler / Inventory "Whack" - Forcing a Full vCenter Resync

IP Spaces Migration - Terraform and Legacy API Breakage

Zerto Custom Guest Properties Sync Failure on Failback

Kubernetes (CSE) Backup - The Full Picture

Three topics from the preceding sections warrant visual treatment. The compatibility matrix is a reference you will check before every upgrade. The Kubernetes backup architecture shows why the tooling shift is necessary. The CDP trace-through is the exact diagnostic path from tenant complaint to root cause.

VCD / Veeam VBR / vCenter Upgrade Lockstep Matrix

Every cell is a verified compatibility state sourced from Veeam KB4488 and KB2443. Red cells are confirmed breakage points - upgrading in that combination breaks the integration immediately. Upgrade VBR before VCD. Upgrade vCenter within the validated range for your VBR version. Check the KBs before every upgrade.

The Kubernetes Backup Disconnect - Traditional VBR vs. the Reality

This is the architectural mismatch that catches MSPs off guard. Standard VBR job protects compute. It does not protect Kubernetes control plane state. Here is exactly what each approach captures and misses, and the two-phase recovery that results.

The CDP Storage Ghost - Traced From Tenant Complaint to Root Cause

The symptom is obvious. The cause is three layers deep and invisible at each layer above it. Engineers who do not know this path waste hours checking the wrong things.

2025 was a big year for both platforms. Veeam shipped v13, Zerto shipped 10.8, and if you run VCD as your cloud delivery platform you need to know exactly what changed and what it means for your upgrade planning. Here is the straight version.

Veeam v13 (13.0.1, November 2025) - What MSPs Need to Know

Where Things Stand Now

Build	Date	Cloud Connect / VCD	Notes
VBR 13.0.1 (GA)	November 19, 2025	FULL SUPPORT	Windows + Linux (Veeam Software Appliance). Full Cloud Connect, full VCD integration. VSPC v9 required. In-place upgrade from VBR 12.3.1+ (build 12.3.1.1139 or later).
VBR 13.0.1 Patch 2 (current)	March 12, 2026	FULL SUPPORT	Build 13.0.1.2067. Current recommended build. Includes security patches. See KB4738 for known issues still open at this build.

The Cloud Connect Upgrade Sequence - SP Goes First, Every Time

VBR v13 New Features Relevant to VCD Environments

Universal CDP to VCD: The headline v13 feature for MSPs. CDP in v12 was vSphere-only on the source side. v13 opens it to any Windows machine - physical servers, VMs on any hypervisor, cloud instances - with VCD as the replication target. You can now pitch sub-second RPO DRaaS to tenants running bare-metal or Hyper-V workloads and deliver it over your existing Cloud Connect Replication infrastructure. More target hypervisors are coming in future releases, but VCD is supported at GA.

Veeam Software Appliance (VSA): Rocky Linux under the hood, DISA STIG hardened at deployment, OS updates managed by Veeam. No Windows Server license. The actual VBR code is identical between Windows and VSA in 13.0.1 - you get the same feature set either way. If you are running VBR on Windows today and want to move to VSA, the path is: upgrade Windows VBR to 13.0.1 first, then use conversion tooling. You cannot jump directly from v12 Windows to v13 VSA - the intermediate Windows upgrade step is required.

Web UI: Finally. v13 ships a proper web-based management console that sits alongside the Windows UI. Both are supported. The web UI covers the day-to-day backup and restore operations well, though it does not yet have full parity with the Windows console for every advanced operation. Good enough for most work, and it will catch up over time.

v13 Upgrade Blockers - Check These Before Upgrading:

Blocker	Check	Remediation
Backup jobs with metadata still in v11 format	VBR console shows warning on affected jobs	Run a full active full backup to upgrade metadata to v12 format before upgrading to v13
Backup Copy jobs in legacy mode	Settings show "legacy" in job properties	Resync backup copy jobs to convert to per-machine chain format before upgrading
Veeam Agent for Windows older than v6	Check agent versions in managed agents list	Upgrade agents to v6.3.1+ before upgrading VBR to v13
Reversed incremental backup mode in use	Job settings show reversed incremental	Convert affected jobs to forward incremental. New jobs cannot use reversed incremental in v13.
VBR version older than 12.3.1	Check current build in Help > About	Upgrade to 12.3.1 (build 12.3.1.1139) minimum before upgrading to v13. In-place upgrade only supports from 12.3.1+.

v13 Known Issues Relevant to VCD

---

HPE Zerto 10.x - Current State for VCD Environments

Current Version Landscape

Zerto Version	Status	Key Change
Zerto 9.7	Critical Support (EOSL approaching)	Last version with Windows ZVM support. ZVMA available but optional.
Zerto 10.0	General Support	Windows ZVM removed. ZVMA mandatory. Major architecture change.
Zerto 10.7	General Support	Security hardening, ICMP blocked by default
Zerto 10.8	General Support - Current	VCF 9.0 support, host attestation for vault recovery, CrowdStrike integration

Zerto and VCD 10.6 - The AMQP/MQTT Reality

Zerto's VCD integration uses the RabbitMQ AMQP messaging path to receive VCD events. VCD 10.6 deprecated AMQP in favor of MQTT, so the obvious question is: when does Zerto move to MQTT? That answer is not public yet. What matters right now is that AMQP still works in VCD 10.6.x alongside the deprecated path, so Zerto continues to function as long as you keep RabbitMQ running on 3.10.x, 3.11.x, or 3.12.x.

The Broadcom KB (article 422585) documenting the VCD 10.6.1.1 MQTT/AMQP disconnect explicitly names Zerto as the affected external service. The short-term fix is the RabbitMQ connection for Zerto remains supported in VCD 10.6 alongside the deprecated AMQP path. RabbitMQ 3.10.x, 3.11.x, or 3.12.x is required. The Zerto connection to VCD continues through this AMQP/RabbitMQ path even as AMQP is deprecated for VCD's own internal use.

Zerto 10.x VCD-Relevant Operational Changes

ZVMA mandatory: The Linux ZVMA appliance is now the only supported deployment. This changes your backup and DR posture for Zerto itself - ZVMA backup via snapshot (Zerto provides built-in ZVMA backup configuration), no Windows OS patching concern, Keycloak-based authentication built in.

ICMP blocked by default (10.0_U7 and later): Ping is blocked on the ZVMA as a security measure from 10.0 Update 7 forward. If your monitoring platform pings the ZVMA to check reachability, those checks will start failing false negatives after upgrade. Switch your checks to TCP port connectivity against the Zerto API ports. ICMP can be re-enabled via CLI Option 10 (ICMP Echo Management), but Zerto flags it with a security warning and it is off by default for a reason.

VCF 9.0 support (10.8): Zerto 10.8 added support for VMware Cloud Foundation 9.0 for new deployments. This is relevant for MSPs running VCF-backed VCD infrastructure who are evaluating VCF 9.0 adoption.

Offline recovery and vault integration (10.0 U6+): Zerto added offline recovery mode for use with HPE Cyber Resilience Vault scenarios. Zerto 10.8 added host attestation for vault recovery - a TPM-based host verification process before allowing interaction with sensitive vault data. Relevant for MSPs building ransomware resilience offerings alongside VCD DRaaS.

Zerto 10.x Upgrade Path for VCD Environments

From	To	Action Required
Zerto 9.7 Windows ZVM	Zerto 10.x ZVMA	Use Zerto migration tool. Deploy ZVMA first, migrate config, decommission Windows ZVM. Do not upgrade Windows ZVM in place - it is not supported in v10.
Zerto 9.7 ZVMA	Zerto 10.x ZVMA	Standard upgrade via ZVMA management UI. Backup ZVMA before upgrading. VPGs remain in protection during upgrade.
Zerto 10.x any	Zerto 10.8	Standard upgrade. Verify VCD compatibility in Zerto interoperability matrix for your specific VCD version before upgrading Zerto.

This is the procedure I would follow myself. Not the abbreviated version - the one that actually accounts for what breaks. VCD upgrades are not click-next affairs. Each step has a verification gate. Do not proceed past a failed gate.

Pre-Upgrade Checklist (Complete Before Maintenance Window)

Item	Command / Action	Expected Result
Check current VCD version and build	VCD UI: Help > About, or rpm -qa | grep vmware-vcd	Know your starting point exactly
Confirm all cells are healthy	VCD UI: System > Server Configuration > Manage Cell Cluster	All cells show Active status
Snapshot all VCD cell VMs	vCenter: right-click each cell VM > Take Snapshot	Snapshots created and visible
VCD database backup	/opt/vmware/appliance/bin/create-backup.sh on primary cell	Backup file created in transfer/backups
Verify backup file is not zero bytes	ls -lh /opt/vmware/vcloud-director/data/transfer/backups/	File exists with non-zero size and recent timestamp
Check PostgreSQL disk space	df -h /var/vmware	At least 8 GB free before upgrade
Check root disk space on all cells	df -h /	At least 10 GB free
Verify vCenter and NSX connectivity	VCD UI: Resources > Infrastructure Resources - all green	No connection errors on vCenter or NSX
Confirm RabbitMQ is healthy	VCD Admin UI: Administration > General Settings > AMQP - Test connection	Connection test passes
Check for stale AMQP settings (if upgrading from pre-10.1)	GET /api/admin/extension/settings/amqp	Know whether AMQP settings exist that need cleanup
Confirm Veeam plugin version	VCD UI: Administration > Customize Portal > UI Plugins	Note current plugin version - will need update after upgrade
Notify Zerto of upcoming maintenance	Email / ticketing system	Zerto team aware VCD upgrade is occurring
Download the target VCD ISO	Broadcom Support Portal	ISO downloaded and accessible from all cells
Verify ISO checksum	sha256sum VMware_Cloud_Director-{version}.iso	Matches Broadcom published checksum

The Upgrade Sequence

If the Upgrade Fails Midway

The cell-management-tool (CMT) is used constantly throughout this guide as the fix mechanism for bugs, configuration issues, and maintenance tasks. A quick reference for every CMT command you will actually need in production. All commands are run on a VCD cell as root unless otherwise noted. Commands that modify configuration need to be run on the primary cell only - settings propagate via the database.

Cell and Service Management

Purpose	Command
Graceful cell shutdown (drain tasks first)	cell-management-tool cell -i $(service vmware-vcd pid cell) -s
Show cell status	cell-management-tool cell -i $(service vmware-vcd pid cell) -S
Show all cells in cluster	cell-management-tool cell -l
Put cell in maintenance mode	cell-management-tool cell -m
Remove cell from maintenance mode	cell-management-tool cell -r
Decommission a cell (remove from cluster)	cell-management-tool deregister

Certificate Management

Purpose	Command
Import vSphere and NSX infrastructure certs	cell-management-tool trust-infra-certs --vsphere --unattended
Import HTTPS certificate	cell-management-tool certificates -j --cert /path/cert.pem --key /path/key.pem --key-password {pass}
Remove legacy console proxy settings	cell-management-tool clear-console-proxy-settings
List certificates in trust store	cell-management-tool certificates -l

Configuration Management

Purpose	Command
Set a configuration property	cell-management-tool manage-config -n {property.name} -v {value}
Read a configuration property	cell-management-tool manage-config -n {property.name} -l
Set audit trail retention (days)	cell-management-tool manage-config -n com.vmware.vcloud.audittrail.history.days -v 45
Set task history retention (days)	cell-management-tool manage-config -n com.vmware.vcloud.tasks.history.days -v 30
Set relocate task timeout (minutes)	cell-management-tool manage-config -n relocate.vm.workflow.timeout.minutes -v 20
Set ORG_TRAVERSE log spam fix	Add to log4j.properties: log4j.logger.com.vmware.ssdc=INFO
Enable/disable FIPS mode	cell-management-tool manage-config -n com.vmware.vcloud.fips.enabled -v {true|false}

VM and VApp Discovery

Purpose	Command
Trigger VM auto-import discovery	cell-management-tool debug-auto-import -v {vm-moref}
Force full vCenter inventory resync	cell-management-tool resync-vc

Most-Used CMT Commands in This Guide

If you are a VMware Cloud Service Provider, Usage Meter runs alongside VCD and is how Broadcom tracks your consumption for VCSP billing. It is frequently under-documented and over-ignored until something breaks. Here is what you need to know operationally.

What Usage Meter Does

Usage Meter collects consumption data from VCD (and other VMware products in your stack) and reports it to Broadcom for monthly billing under your VCSP contract. It connects to VCD via a read-only service account and polls usage at regular intervals. The data it collects feeds your monthly commerce portal report. If Usage Meter is not running or cannot reach VCD, your reported consumption will be inaccurate - either under-reported (you pay less but risk compliance issues) or missing data that creates dispute scenarios with Broadcom.

Usage Meter + VCD Integration Requirements

Requirement	Detail
Usage Meter version	Must be compatible with your VCD version. Check the VMware Product Interoperability Matrix. For VCD 10.6.x, use Usage Meter 4.7 or later.
VCD service account	Create a dedicated VCD service account for Usage Meter with read-only System Administrator rights. Do not use the vcd-system-admin account.
Network access	Usage Meter must reach VCD API on TCP 443. Usage Meter must also reach Broadcom's commerce portal endpoints outbound (HTTPS). Proxy configurations are supported.
VCD API version	Usage Meter uses specific VCD API versions. If you upgrade VCD to a version that drops an old API, verify Usage Meter compatibility before the upgrade.
SSL trust	Usage Meter must trust the VCD SSL certificate. If using a private CA, import the CA root into Usage Meter's trust store.

Setting Up the VCD Service Account for Usage Meter

Common Usage Meter Issues in VCD Environments

Monitoring Usage Meter

Veeam with VCSP Licensing

If you are selling Veeam-powered backup as part of your VCSP offering, note the distinction between Veeam Cloud Connect licensing (per-workload tenant billing through VCSP) and Veeam's own usage reporting. Veeam Cloud Connect tracks tenant consumption for your own billing but this is separate from what Usage Meter reports to Broadcom. You manage these two billing streams independently.

VSPC v9 (required alongside VBR 13.0.1) provides enhanced VCSP-specific reporting that helps consolidate your view of tenant consumption across both the VCD and backup dimensions. If you have not yet upgraded to VSPC v9, the reporting improvement is a genuine operational benefit alongside the required VBR v13 compatibility.

The three-tier model (Provider, Sub-Provider, Tenant) is one of the most powerful things VCD 10.6 offers MSPs who wholesale to resellers. This walkthrough covers the actual setup from scratch, not just the concepts. By the end, a reseller (Sub-Provider) will be able to create and manage their own tenants without ever needing your provider credentials.

Architecture Overview

Three-Tier Tenancy Model

In the three-tier model:

Provider (you) - owns the physical infrastructure, creates Provider VDCs and resource pools, manages NSX, manages RabbitMQ, sets global limits.

Sub-Provider (your reseller) - receives a delegated quota of compute, storage, and network resources from you. Creates and manages their own tenant organizations within their quota. Cannot see or modify provider infrastructure.

Tenant (the reseller's customer) - gets an Organization VDC from the Sub-Provider. Has no awareness of the provider layer at all.

Step-by-Step: Creating a Sub-Provider Organization

What the Sub-Provider Can and Cannot Do

Action	Sub-Provider Can	Sub-Provider Cannot
Create tenant organizations	Yes - within their scope	Cannot create organizations outside their Sub-Provider org
Manage tenant users and roles	Yes - for their tenants	Cannot modify system roles or other Sub-Providers' users
Create Organization VDCs	Yes - using granted Provider VDC resources	Cannot access Provider VDCs not granted to them
Manage network pools and segments	Within their Org VDCs	Cannot modify NSX, create network pools, or modify provider gateways
Manage IP Space quotas	Can allocate IPs to tenants from their quota	Cannot modify the provider-level IP Space or expand their own quota
Publish catalogs	Can publish catalogs to their tenant organizations	Cannot publish to organizations outside their scope
View provider infrastructure	No visibility	No access to physical infrastructure, NSX, vCenter
Resolve provider-level resource exhaustion	Cannot - must escalate to Provider	Cannot add resources to Provider VDC

Billing Considerations for Three-Tier Deployments

In a three-tier model, you need a billing model that accounts for the reseller layer. Common approaches:

Wholesale commitment model: The reseller commits to a monthly resource reservation (e.g., 100 vCPU, 1 TB RAM, 20 TB storage). You invoice the reseller at the committed rate regardless of how much their tenants use. The reseller marks up and invoices their own tenants. Simplest operationally - one billing relationship per reseller.

Consumption pass-through: The reseller passes actual consumption to their tenants. You invoice the reseller based on actual Usage Meter data. More accurate but requires the reseller to have their own billing system that can ingest VCD usage data. VSPC can help with this if the reseller also uses Veeam.

For most MSP-to-reseller relationships, the wholesale commitment model is the right choice. It simplifies your operations, gives the reseller predictable costs, and gives you predictable revenue.

VCD Disaster Recovery Decision Tree

Every runbook covers what happens when tenant VMs fail. Almost none cover what happens when VCD itself goes down. That scenario is what this section covers - the primary cell is gone, the database is corrupted, or the entire site is lost. These are low-probability but high-consequence events, and the time to figure out your recovery procedure is not while VCD is down and tenants are calling.

What the VCD Backup Actually Contains

The VCD appliance backup (create-backup.sh) creates a ZIP file in the transfer directory containing the PostgreSQL database dump and the VCD configuration files. It does not back up the VM files themselves - those are on your datastores. It does not back up NSX or vCenter configuration. What it gives you is the VCD brain: the database of all tenant organizations, VDCs, catalogs, users, network configurations, and task history. Without this, rebuilding VCD means recreating every tenant by hand.

Copy Backups Off the Cell

The backup file sitting on the transfer volume of the VCD cell is not a backup - it is a copy. If you lose the cell VM and its datastore, you lose the backup too. Move backup files to an external location immediately after creation.

Scenario 1 - Single Cell Failure (Multi-Cell Deployment)

A cell VM crashes or becomes unresponsive. Other cells are still running. VCD is degraded but functional - the load balancer routes around the dead cell.

Scenario 2 - Primary Cell Database Corruption

The PostgreSQL database is corrupted or the primary cell vPostgres service will not start. Secondary cells cannot connect. VCD is completely down.

Scenario 3 - Complete Site Loss

The entire VCD site is gone - data center disaster, power failure with corrupted storage, or catastrophic hardware failure. No VMs, no storage. You are rebuilding from offsite backups.

What Veeam and Zerto Do When VCD Is Down

This is the question nobody asks until it matters. Here is the exact behavior of each platform when VCD itself is unavailable:

Platform	What Keeps Working	What Breaks	Recovery Trigger
Veeam VBR (agent backup)	Agent backup jobs continue running. Backups write to the cloud repository normally. VBR communicates directly with the Veeam agent on the VM - no VCD involvement.	Tenant Self-Service Backup Portal (requires VCD API). New Cloud Connect tenant onboarding. Any operation that needs VCD org credential validation.	Portal access restores when VCD comes back up. No manual intervention needed for running jobs.
Veeam Cloud Connect Replication	Existing replication jobs continue. The Cloud Gateway communicates directly with source Veeam servers. VCD is not in the data path for replication.	Replica management through VCD portal. New replica job creation. Failover operations that use VCD API to power on replicas in the Org VDC.	Failover operations require VCD to be available. This is the critical dependency - if you need to failover during a VCD outage, you will need to perform the failover manually in vCenter instead.
Zerto VPG Replication	Replication continues at the ZVM level. Journal checkpoints continue being written. VPG protection is maintained. The ZVMA and ZVMs communicate directly with each other.	VCD event awareness. Organization-level failover through VCD portal. ZCM operations that depend on VCD API responses. The Zerto tenant self-service portal if it depends on VCD authentication.	Failover can still be triggered directly through the ZVMA management interface or the Zerto API, bypassing VCD. You lose the VCD-integrated workflow but not the failover capability itself.

VCD Multisite Federation Architecture

VCD multisite lets you tie two or more geographically separate VCD installations together so they can be managed and accessed as a unified platform. MSPs running multiple availability zones or data centers need this to offer tenants a consistent experience across sites without managing separate VCD credentials for each location.

What Multisite Is and Is Not

Multisite is a management and identity federation feature. It is not a replication or HA feature. When you associate two VCD sites, organization users can log in at Site A and see their assets at Site B - but the data stays local to each site. Catalogs can be published and subscribed across sites. Organization associations let users access multi-site resources from a single portal session.

What multisite does not do: replicate tenant VMs between sites, synchronize Org VDC configurations between sites, or provide automatic failover. That is what Zerto and Veeam replication do. Multisite handles the identity and management plane. Zerto and Veeam handle the data plane.

Multisite Prerequisites

Requirement	Detail
API version compatibility	Sites must be on the same VCD API version or one major version apart. For VCD 10.6.x sites, all sites should be on 10.6.x for full feature compatibility.
Network connectivity	Each VCD site must be able to reach the other site's API endpoint on TCP 443. The association uses certificate-based mutual authentication. No VPN is required if both sites are internet-accessible, but a private interconnect is strongly recommended for production.
Valid SSL certificates	Both sites must have valid SSL certificates. Self-signed certificates work if each site's certificate is trusted by the other, but CA-signed certificates are easier. The association will fail if certificate validation fails between sites.
Unique installation IDs	Each VCD site must have a unique installation ID. If you built your secondary site by cloning the primary appliance, the installation IDs will be identical and multisite will fail. Regenerate the installation ID on the cloned site before creating the association.
System admin access at both sites	Creating the site association requires System Administrator credentials at both sites. Organization associations require Org Admin credentials at both orgs.

Creating a Site Association

Creating Organization Associations

A site association lets the sites talk to each other. An organization association lets a specific tenant org at Site A access assets at a corresponding org at Site B. These are created separately and are tenant-controlled (the org admin does this, not the system admin).

Multisite Catalog Publishing

One of the most useful multisite features for MSPs is cross-site catalog publishing. A gold image catalog at Site A can be subscribed to at Site B. Tenants at both sites get access to the same templates without manual duplication.

Multisite and Veeam/Zerto

Multisite federation is a management plane feature. It does not change how Veeam or Zerto connect to VCD. Each VCD site needs its own Veeam Cloud Connect server (or the same VBR registered to both sites). Zerto Cloud Manager connects to each VCD site independently. There is no automatic federation of Veeam or Zerto configuration across VCD sites - you manage each site's protection stack separately, even if tenants see them as a unified organization.

This deserves its own section because it has blocked production upgrades in environments that did everything else right. VCD 10.6.1 added a security enhancement that validates the PostgreSQL certificate's Subject Alternative Name contains the database server's IP address. If you used a custom CA-signed certificate for PostgreSQL without the IP in the SAN, the upgrade fails immediately. Default self-signed certificates generated by the VCD appliance are not affected - this only hits environments that replaced the PostgreSQL certificate with a CA-signed one.

How to Know If You Are Affected Before Upgrading

Option A - Regenerate the PostgreSQL Certificate with IP in SAN (Preferred)

This is the clean fix. It requires a brief PostgreSQL restart but no VCD downtime if done before the upgrade.

Option B - Add SSL Mode to JDBC URL (No Certificate Replacement)

If you cannot replace the PostgreSQL certificate before the upgrade (for example, if your internal CA has a slow turnaround), this workaround bypasses the SAN validation by switching the connection to explicit SSL mode. It is documented in Broadcom KB 388974.

Month-end at a VCSP is when Usage Meter problems that went unnoticed all month become billing problems. The reconciliation workflow below covers what to do when the numbers do not match what you expect - and how to open a dispute with Broadcom when the gap is their collection failure, not yours.

The Month-End Workflow

When the Numbers Do Not Match

Opening a Billing Dispute with Broadcom

If your Usage Meter report has a gap due to a confirmed collection failure and you believe you are being billed for a period where Usage Meter was not collecting accurately, you can open a dispute through the VCSP support channel. The process:

Gather evidence: Usage Meter collection logs showing the gap, any error messages from the period in question, and your own VCD allocation data for the gap period. Open a VCSP support case through the Broadcom support portal, explicitly tagged as a billing dispute. Provide the evidence and specify the gap period and the estimated correct consumption. Broadcom typically takes 2-4 weeks to review and respond. Disputes are evaluated on a case-by-case basis. Having clean logs and clear evidence is the difference between a quick resolution and a long back-and-forth.