> ## Documentation Index > Fetch the complete documentation index at: https://docs.cloudthinker.io/llms.txt > Use this file to discover all available pages before exploring further. # VMware vCenter > Connect vCenter so agents can inventory VMs, hosts, and datastores, audit snapshots and capacity, and run VM changes through approvals Connect vCenter Server so CloudThinker can inventory your VMs, hosts, clusters, and datastores, find oversized VMs and stale snapshots, and make VM changes through your [Approvals](https://docs.cloudthinker.io/guide/approvals/overview.md). The connection signs in with a **vCenter user name and password**, and the vSphere role you give that user decides what agents can see and change. ## Prerequisites * A **vCenter Server** that CloudThinker can reach over HTTPS by hostname or IP address. The default port is `443`. * A vSphere Client account in the SSO **Administrators** group, such as `administrator@vsphere.local`, to create the user and assign a global permission. * A CloudThinker workspace with no VMware vCenter connection yet. > [!NOTE] > > A workspace holds **one** VMware vCenter connection. The connection runs in the CloudThinker cloud, so vCenter must accept HTTPS on its port from the internet. To keep it otherwise private, allow only CloudThinker's egress IPs. These docs don't publish CloudThinker's egress IP list: ask your CloudThinker contact, or [contact us](https://cloudthinker.io/contact). See [Reaching private services](https://docs.cloudthinker.io/guide/connections/overview.md#reaching-private-services) for other options. ## Setup **1. Create a vCenter user** In the vSphere Client, open **Administration → Single Sign On → Users and Groups**. Select your SSO domain (`vsphere.local` on a default install), open the **Users** tab, click **Add**, and create a user such as `cloudthinker` with a strong password. A new user starts with no privileges. > [!WARNING] > > Local SSO passwords expire after 90 days under vCenter's default policy, and the connection breaks when this one does. Change the policy in **Administration → Single Sign On → Configuration**, or plan a rotation and update the password in CloudThinker through [Rotate the password](#rotate-the-password). **2. Give the user the Read-only role** Open **Administration → Access Control → Global Permissions** and click **Add**. Choose the domain, search for the user, select the **Read-only** role, and tick **Propagate to children**. Click **OK**. > [!WARNING] > > Without **Propagate to children**, the user sees only the root object and agents report an empty inventory. To share less, skip the global permission and assign the role per object: select a datacenter, cluster, or folder, open its **Permissions** tab, click **Add**, choose the user and the **Read-only** role, and tick **Propagate to children**. **Success state:** the user appears in the global permissions list (or the object's **Permissions** tab) with the **Read-only** role. **3. Add the connection in CloudThinker** In the sidebar, click **More → Workspace settings → Connections** and select **VMware vCenter**. Fill in the fields from [Connection details](#connection-details): the host, `cloudthinker@` as the user name (for example `cloudthinker@vsphere.local`), the password, and the port. Before you click **Connect**, open `https://` in a browser. If the browser trusts the certificate, leave **Verify SSL certificate** selected. If it warns, install a certificate from a trusted authority on vCenter, or, on a lab system only, select **Skip SSL verification**. Otherwise the test fails. Click **Connect**. **Success state:** the connection shows **Connecting** and **Verifying**, then a **Connected** status. CloudThinker signs in to vCenter and reads its version to prove the credentials work. ## Connection details The form shows these field names exactly as written here. All five are required. Port and SSL come prefilled. | Field | Required | Description | Example | | - | - | - | - | | **VMWARE\_HOST** | Yes | vCenter hostname, IPv4 address, or IPv6 address in brackets. No `https://` and no path | `vcenter.example.com` | | **VMWARE\_USERNAME** | Yes | vCenter user name, as `user@` | `cloudthinker@vsphere.local` | | **VMWARE\_PASSWORD** | Yes | Password of that user | `********` | | **VMWARE\_PORT** | Yes, prefilled | Port vCenter listens on. Defaults to `443` | `443` | | **VMWARE\_VERIFY\_SSL** | Yes, prefilled | **Verify SSL certificate** (default) or **Skip SSL verification** | **Verify SSL certificate** | There is no field for a custom certificate authority. If vCenter uses a self-signed certificate (common on default installs and labs), **Skip SSL verification** is the only way to connect. It also removes protection against a server impersonating your vCenter, so use it for lab systems and give production vCenter a certificate from a trusted authority. ## Required permissions Start with the built-in **Read-only** role. vSphere lets users with this role view the state and details of an object, and blocks every action in the menus and toolbars. It covers every read capability below. > [!TIP] > > Keep the CloudThinker user on **Read-only** until you want agents to make changes. If a question fails with a permission error, add only the privilege vCenter names, on as few objects as you can. ## Write access To let agents power, reconfigure, migrate, snapshot, or delete VMs, create a custom role in **Administration → Access Control → Roles** (click **New**), add only the privileges below for the changes you want, then assign it: 1. Select the datacenter, cluster, folder, or VM in scope and open its **Permissions** tab. 2. Click **Add**, choose the CloudThinker user and the custom role, and tick **Propagate to children**. Click **OK**. A permission set directly on an object overrides the inherited **Read-only** role there. Every custom role includes read access, so agents still see those objects. | Change | vSphere privileges | Where they sit in the role's privilege tree | | - | - | - | | Power on, off, or reset | `VirtualMachine.Interact.PowerOn`, `VirtualMachine.Interact.PowerOff`, `VirtualMachine.Interact.Reset` | **Virtual machine → Interaction** | | Change CPU or memory | `VirtualMachine.Config.CPUCount`, `VirtualMachine.Config.Memory` | **Virtual machine → Change Configuration** | | Create or remove snapshots | `VirtualMachine.State.CreateSnapshot`, `VirtualMachine.State.RemoveSnapshot` | **Virtual machine → Snapshot management** | | Migrate | `Resource.HotMigrate`, `Resource.ColdMigrate`, `Resource.AssignVMToPool`, plus `Datastore.AllocateSpace` when storage moves | **Resource** and **Datastore** | | Delete | `VirtualMachine.Inventory.Delete` | **Virtual machine → Edit Inventory** | For migrations, also assign the role on the destination host or cluster, resource pool, and datastore. To change CPU or memory on a powered-on VM, the VM needs CPU or memory hot-add enabled in vSphere. Without it, the VM must be powered off first, which means downtime. If a change fails with a permission error, vCenter names the missing privilege. Add that one and nothing broader. **Allow writes** on the connection's detail panel is the second control. It's on by default, but the **Read-only** role can't change anything, so vCenter refuses every change until you grant a custom role. | vSphere role on the CloudThinker user | Allow writes | Result | | - | - | - | | **Read-only** only | On or off | Read-only. vCenter rejects every change. | | A custom role with write privileges | Off | Read-only. CloudThinker refuses every change before it reaches vCenter. | | A custom role with write privileges | On | Agents can propose changes. Your [Rules and Approval mode](https://docs.cloudthinker.io/guide/approvals/overview.md) decide each one. | To lock writes in CloudThinker as well, open **VMware vCenter** in **More → Workspace settings → Connections** and turn off the **Allow writes** switch on its detail panel. Every change an agent makes goes through your workspace's [Approvals](https://docs.cloudthinker.io/guide/approvals/overview.md) first. On the default **Auto · Rules + AI · Ask me** mode, AI judgment can let a safe change run without asking — and an Allow Rule can too, once CloudThinker turns on [Rule enforcement](https://docs.cloudthinker.io/guide/approvals/rules.md#troubleshooting) for your workspace. Choose **Manual** to approve every change yourself. On a production vCenter, choose **Manual** so a person approves every change — that is the control that works today. Once CloudThinker turns on [Rule enforcement](https://docs.cloudthinker.io/guide/approvals/rules.md#troubleshooting) for your workspace, an **Ask first** [Rule](https://docs.cloudthinker.io/guide/approvals/rules.md) can narrow the wait to power-off and delete. See [Approvals](https://docs.cloudthinker.io/guide/approvals/overview.md) for who approves. ## Agent capabilities | Capability | What agents do | | - | - | | **Inventory** | List datacenters, clusters, hosts, VMs, datastores, and networks, and inspect one object in detail | | **Tags** | Read tag categories and the objects they are attached to | | **Right-sizing** | Flag powered-on VMs with 8 or more vCPUs whose average CPU usage is under 15%, from vCenter's 5-minute samples | | **Snapshots** | List snapshots by VM and flag ones older than 7 days | | **Datastore capacity** | Show used and free space and flag datastores more than 85% full | | **Drift** | Compare host settings (NTP, syslog, SSH service, lockdown mode) and flag risky port group security options such as promiscuous mode | | **Changes** | Power, change CPU or memory, migrate, snapshot, or delete VMs. Each change goes through [Approvals](#write-access), so a person approves it on **Manual** | The 15% CPU, 8 vCPU, 7-day, and 85% thresholds are defaults. Name a different number in your question, such as `snapshots older than 30 days`. Answers cover only what the user's role can see. ### Get better right-sizing data Agents request up to 14 days of 5-minute samples, but vCenter keeps them for 1 day by default (5 days at most). Agents don't use the longer 30-minute interval. To keep 5 days: 1. In the vSphere Client, select the vCenter Server. 2. Open **Configure → Settings → General** and click **Edit**. 3. Open **Statistics** and set the 5-minute interval to keep samples for 5 days. Save. The right-sizing average then covers up to the last 5 days. ### Verify the connection ```text theme={null} Summarize my vCenter inventory: datacenters, clusters, hosts, VMs, and datastores ``` You get counts per object type and a short list of clusters and hosts. An empty inventory on a **Connected** status points to a missing **Propagate to children**. ### Example prompts ```text theme={null} Which powered-on VMs have used under 15% CPU recently and have 8 or more vCPUs? List snapshots older than 7 days, grouped by VM Which datastores are above 85% full? ``` ## Rotate the password VMware vCenter is a single-connection service, so it has no pencil icon or **Edit Instance** dialog while it's healthy. | When | How | | - | - | | Before the password expires | Set the new password on the vCenter user, then click **Disconnect** on the **VMware vCenter** detail panel and connect again with the new value. | | After it expires (the connection shows **Error**) | Set the new password on the vCenter user, then click **Replace credentials** on the detail panel and save the new value. | Change the password in vCenter first, then update CloudThinker. The connection keeps signing in with the saved password, so it breaks between the two steps. Rotate early, in a quiet period, rather than letting the password expire into an outage. Reconnecting starts a new connection: * Agents and scheduled [automations](https://docs.cloudthinker.io/guide/automation/automations.md) can't use vCenter between the disconnect and the reconnect. * Discovery runs again and spends credits. * **Allow writes** goes back to on. Turn it off again if you had it off. * Check that [Rules](https://docs.cloudthinker.io/guide/approvals/rules.md) naming the VMware vCenter connection still list it. ## Troubleshooting > [accordion] Failed to connect to VMware vCenter > > CloudThinker could not sign in. Check that the user name includes its SSO domain (such as `cloudthinker@vsphere.local`), the password is current, and the host and port are reachable from the internet. A self-signed certificate also fails here unless **Skip SSL verification** is selected. > [accordion] VMWARE\_HOST must be a DNS hostname, IPv4, or bracketed IPv6 > > The host field has a scheme, a path, or an unbracketed IPv6 address. Enter only the host, such as `vcenter.example.com`, `192.0.2.10`, or `[2001:db8::10]`. > [accordion] VMWARE\_PORT must be an integer between 1 and 65535 > > The port has letters or is out of range. Enter a number such as `443`. > [accordion] Invalid VMware connection configuration > > The host field is empty. Enter your vCenter hostname or IP address and connect again. > [accordion] Connection 'vmware' already exists. Only one instance is allowed. > > This workspace already has a VMware vCenter connection. Edit that connection or disconnect it first. > [accordion] Failed to connect to VMware vCenter on a connection that used to work > > The CloudThinker user's SSO password most likely expired (90 days by default) or the account is locked. An SSO administrator opens **Administration → Single Sign On → Users and Groups**, selects the user on the **Users** tab, and unlocks it or sets a new password. Then enter the new password through [Rotate the password](#rotate-the-password): VMware vCenter has no pencil icon, so you click **Replace credentials** on the detail panel while the connection shows **Error**. > [accordion] An agent cannot see a VM, host, or datastore > > The user's role does not cover that object. Check that the global permission has **Propagate to children** ticked, or assign the role on the object's parent folder or cluster. ## Security * **Least privilege** — grant only the permissions the agents need for your use case; start read-only and widen later. * **Read-only by default** — use read-only credentials unless you want agents to make changes through this connection. * **Rotate credentials** — rotate keys and tokens on your normal schedule; CloudThinker picks up the new value when you update the connection. * **Revoke on offboarding** — remove the credential at the provider when you delete a connection or a teammate leaves. - **Use a dedicated user.** A separate vCenter user keeps CloudThinker's access visible in vCenter events and lets you revoke it without touching anyone's account. - **Keep certificate checks on.** Reserve **Skip SSL verification** for lab systems with self-signed certificates. - **Plan for password expiry.** Local SSO passwords expire after 90 days by default. Change the policy, or update the password before it expires through [Rotate the password](#rotate-the-password). - **Revoke at the source.** Remove the user's permission in vCenter, or disable the user in **Single Sign On → Users and Groups**. ## Related > [card] [Approvals](https://docs.cloudthinker.io/guide/approvals/overview.md) > > Control which VM changes agents can run and who approves them > [card] [Connections Overview](https://docs.cloudthinker.io/guide/connections/overview.md) > > How connection status, testing, and discovery work This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.