VMware Integration
Connect to vCenter Server via the vSphere REST API to automatically discover and import virtual machines, hosts, clusters, datastores, and networks into the Clarity CMDB — the fastest way to build an accurate inventory for a VMware-based environment.
Overview
The VMware integration connects Clarity Migrate directly to your VMware vCenter Server using the vSphere REST API. Once connected, Clarity can perform automated discovery runs that pull the complete virtual infrastructure inventory — VMs, ESXi hosts, clusters, datastores, datacentres, port groups, and distributed port groups — and create or update corresponding records in the Clarity CMDB.
Because discovery is performed via the live API rather than file exports, the data is always up to date. You can run discovery on demand or schedule it to run nightly so the CMDB reflects the current state of your environment before each planning session.
Prerequisites
Ensure all of the following are in place before creating a VMware integration endpoint. Missing any one of these will prevent a successful connection.
- VMware vCenter 6.7 or later. The integration uses the vSphere REST API which requires vCenter 6.7+. Legacy vCenter versions using only the SOAP API are not supported.
- Service account with Read-Only access. Create a dedicated service account in vCenter with Read-Only access to the entire inventory (or the specific datacentres you want to discover). The account does not need any write permissions.
- Network connectivity. The Clarity server must be able to reach the vCenter API on HTTPS (port 443) by hostname or IP address.
- Credentials stored in the vault. The vCenter service account credentials must be saved in Administration → Credentials before you create the endpoint. The endpoint save will fail if no credential is available to select.
Configuration
Follow these steps to add and configure a VMware integration endpoint in Clarity.
Navigate to Administration → Credentials → Add. Enter the vCenter service account username and password, set the Type to VMware, give it a descriptive name (e.g. vCenter-Prod-ReadOnly), and click Save.
The credentials are encrypted and stored in the vault — you will reference them by name when creating the endpoint.
Go to Integrations → Integration Endpoints and click Add Endpoint.
In the Type dropdown, select VMware. The form will update to show VMware-specific fields.
- Name — a friendly label for this endpoint (e.g. vCenter Production).
- vCenter URL — the full HTTPS URL of your vCenter Server (e.g.
https://vcenter.company.com). - Credential — select the credential you saved in Step 1 from the dropdown.
- API Version — leave this at the default unless instructed otherwise by support.
Click Test Connection. A green success banner confirms that Clarity can authenticate to vCenter and reach the API. If the test fails, verify the URL, check network connectivity, and confirm the service account credentials are correct.
Click Save. The endpoint will now appear in the Integration Endpoints list and will be available to select when running a discovery.
Running a Discovery
Once an endpoint is configured, you can run a discovery at any time to import or refresh the inventory from vCenter.
Navigate to Integrations → VMware.
Choose the configured vCenter endpoint from the dropdown. If you have multiple vCenter instances, each will appear as a separate endpoint.
Click Run Discovery to start the import. A progress bar tracks the import status in real time.
When complete, go to Integrations → History to see the discovery run log. The log shows the count of devices, hosts, clusters, networks, and storage records imported, along with any errors encountered.
What Gets Imported
The following VMware objects are imported into the Clarity CMDB during a discovery run:
| Source Object | CMDB Asset Type | Notes |
|---|---|---|
| Virtual Machine | Device | VM name, power state, guest OS, CPU, RAM, IP addresses, and assigned host/cluster. |
| ESXi Host | Host | Host name, model, CPU sockets/cores, total RAM, vSphere version, and parent cluster. |
| vSphere Cluster | Cluster | Cluster name, HA/DRS configuration, total CPU/RAM resources, and host count. |
| vSphere Datacentre | Datacentre | Used as a grouping/location tag on child hosts and clusters. |
| Port Group / DPG | Network | Standard and distributed port groups are imported as Network records. VLAN ID is captured where available. |
| Datastore | Storage | Datastore name, type (VMFS/NFS), total capacity, and free space. |
Scheduling
To keep the CMDB automatically in sync with vCenter, set up a recurring background job:
- Navigate to Administration → Background Jobs → Integration Sync — VMware.
- Set the desired schedule (default is daily at 02:00).
- Select which endpoints the job should run against.
- Save the job.
Scheduled discovery runs appear in the Integrations → History log alongside manual runs.
Example Workflow
Before a large migration project kicks off, an infrastructure admin creates three VMware integration endpoints — one for each vCenter instance in the organisation. She runs a discovery against each in sequence.
The combined import creates 847 VM records, 24 ESXi host records, 8 cluster records, and 156 network records in the CMDB — all within 4 minutes.
The migration planning team can now immediately begin scoping workloads, assigning VMs to move groups, and building runbooks — with confidence that the inventory is complete and accurate.
Tips
VMware environments change frequently. Running a fresh discovery before each planning session ensures your CMDB reflects current VM states, including newly provisioned or decommissioned VMs.
- Use the History log to diagnose partial imports. If a discovery completes but some records are missing, check the History log for per-object error messages — they usually point to permission issues or API rate limiting.
- Check for duplicate naming in vCenter. If the same VM appears twice in the CMDB after a discovery, it usually means the VM has identical names in different folders or datacentres in vCenter. Resolve the duplication in vCenter, then run a fresh discovery.
- Create one endpoint per vCenter instance. Even if two vCenters are managed by the same team, each should have its own endpoint so you can discover them independently and track history per environment.
- Use descriptive endpoint names. Naming endpoints like vCenter-DC1-Prod or vCenter-DR makes it clear which environment each endpoint represents when selecting from a list.
Common Mistakes & Troubleshooting
- Using a vCenter account with insufficient permissions. If the service account lacks Read-Only access to part of the inventory, the discovery will run and complete successfully, but those objects simply won't appear in the results. Always verify the service account has Read-Only access to the entire vCenter hierarchy (or the specific datacentres you intend to discover).
- Not storing credentials in the vault before creating the endpoint. The endpoint creation form requires you to select an existing credential from the vault. If no VMware-type credentials have been added, the dropdown will be empty and the endpoint cannot be saved. Always add credentials first.
- Running discovery against a test or lab vCenter instead of production. It's easy to accidentally point the endpoint at the wrong vCenter URL. Double-check the URL before running a discovery — importing lab VMs into your production CMDB creates noise that's time-consuming to clean up.
- SSL certificate errors blocking the connection. If vCenter uses a self-signed certificate, the Test Connection may fail. Either install the vCenter CA certificate on the Clarity server's trusted root store, or consult your administrator about enabling certificate bypass for internal endpoints.