vCloud Director¶
Clarity Transform discovers a multi-tenant VMware Cloud Director estate through the vCD API: organisation VDCs, vApps and their virtual machines, networks, catalogues, and the full policy surface including distributed firewall and edge gateways.
Where to find it¶
Go to Discover → Integrations, then select the vCloud Director card. The card's category label is Cloud. The integration's page has the Endpoints and History tabs; Integrations describes the page, its grid and its row actions.
Why we do this¶
A multi-tenant estate has a structure that a flat inventory cannot express. Which organisation owns a workload, and which vApp it co-deploys with, are migration facts in their own right: they determine what can move independently and what cannot.
The policy surface matters for the same reason it does on a firewall. Where the network is virtualised, this configuration is the network, and reading it directly avoids the guesswork of observing translated traffic.
What we collect¶
- Organisation VDCs, vApps and their virtual machines
- Org and routed networks, and catalogues with their vApp Templates
- Distributed firewall rules, security groups and services
- Each edge gateway's firewall rules, NAT rules, static routes, load balancer and VPN tunnels
Tenant context is enrichment, not a competing inventory
The owning organisation and the vApp a virtual machine co-deploys with are written on top of the canonical vSphere device row rather than as a second source of truth for that machine. So vCD does not fight vSphere for ownership of a VM, and running both is the intended arrangement rather than a conflict.
What it adds¶
Two things it provides on a vCD estate. The tenancy structure, which is what determines whether a workload can move on its own. And the edge gateway policy, including address translation.
Its firewall and load balancer policy feeds application dependency inference the same way the Palo Alto, FortiGate and F5 integrations do, so evidence from a vCD estate is weighed on the same terms as evidence from a physical one.
What is deliberately not inferred¶
- No guest file systems, and no application data.
- Nothing is written. No vApp, virtual machine or policy object is created or changed.
- Coverage is bounded by the credential. A tenant-scoped account discovers that tenant and nothing else. If the whole estate is in scope, that is a scoping question to settle before the first run rather than after.
- Rule order is not evaluated, exactly as on a physical firewall. A permitted path is a lead to verify rather than a conclusion.
What we require¶
The requirement below is read from rb-pautol-vcd-connect.ps1 in the Runbooks repository, which is where it is maintained. If it is wrong, the runbook is what gets corrected and this page follows on the next build.
Account required: an organisation administrator account is the tested baseline, and coverage equals the organisations that account can see. Discovery reads configuration only and never writes.
A system administrator account is needed only for exact matching between vCloud virtual machines and their vSphere counterparts. Without it, matching falls back to network adapter addresses, which is the normal arrangement for a tenant-scoped engagement and is usually sufficient. Do not ask for system administrator by default: it is a materially larger grant for a benefit many engagements do not need.
Connectivity: the vCloud API over HTTPS on TCP 443.
Coverage is bounded by the credential. A tenant-scoped account discovers that tenant. If the whole estate is in scope, the account needs visibility of every organisation in it, and that is a scoping question to settle before the first run rather than after.
Verification before handover¶
- Confirm the account authenticates and see what it can see. Log in to the vCD portal as the account. The organisations listed are the organisations discovery will cover, which makes this the scoping check as well as the authentication one.
- Confirm the policy surface is readable. As the account, open an edge gateway and the distributed firewall. Organisation administrator covers both. A narrower role frequently covers the inventory and not the policy, and that gap presents as a discovered estate with no policy rather than as an error.
- Decide whether exact vSphere matching is needed. It requires a system administrator account, which is a materially larger grant. Without it, matching falls back to network adapter addresses, which is the normal arrangement for a tenant-scoped engagement and is usually sufficient. Settle this deliberately rather than asking for system administrator by default.
Configuring the endpoint¶
On the integration's Endpoints tab, select the add icon (Create New Integration Endpoints). The Create new entry form opens with these fields, in this order:
| Field | Value |
|---|---|
| Name | A name for the endpoint |
| End Point | The vCD API hostname |
| Credential | The stored credential for the organisation administrator account |
| Job Schedule | A five-field cron expression, for example 0 0 * * * (daily) |
| Enabled | Ticked. The box is unticked when the form opens |
The help texts: End Point "FQDN or IP Address of management system for technology e.g. vCenter, Nutanix Prism"; Credential "Credentials can be configured under Settings/Identity and Access Management/Credentials."; Job Schedule "Cron schedule – Use five fields: 〈mm〉 〈hh〉 〈day-of-month〉 〈month〉 〈weekday〉".
The Credential list offers the credentials stored under Settings → Identity & Access Management → Credentials, so create the credential there first.
No field is marked as required. Technology is set by the card and is hidden in the form. Select Save to create the endpoint, or Cancel to close the form. The edit icon opens the same fields as Edit entry.
Removing the access¶
Delete the account in vCD, or remove its role assignment where the account has other uses. Nothing is left behind. Then, in Clarity, remove the endpoint (select its row on the Endpoints tab, then Remove selected) or clear its Enabled box, and remove the credential under Settings → Identity & Access Management → Credentials.
Troubleshooting¶
| Symptom | Cause |
|---|---|
| Fewer organisations discovered than expected | Coverage equals the organisations the account can see. This is a scoping question rather than a fault. |
| Inventory discovered but no firewall or gateway policy | The role covers the inventory and not the policy surface. Organisation administrator covers both. |
| vCloud virtual machines do not match their vSphere counterparts exactly | Expected without a system administrator account. Matching falls back to network adapter addresses. |
| A virtual machine appears once, owned by vSphere | Correct and deliberate. vCD writes tenant context as enrichment on the canonical vSphere row rather than creating a second record. |