Google Distributed Cloud runs in your data center in a vSphere environment. This document describes requirements for your vSphere environment.
Version compatibility
The vSphere requirements vary according to which version of Google Distributed Cloud you are using. For more information, see the version compatibility matrix for fully supported versions and earlier versions.
Supported versions
vSphere is VMware's server virtualization software. vSphere includes ESXi and vCenter Server.
Google Distributed Cloud supports these versions of ESXi and vCenter Server::
- 6.7 Update 3 and later builds of version 6.7
- 7.0 Update 1 and later builds of version 7.0
License requirements
You need the following vSphere licenses:
A vSphere Enterprise Plus or vSphere Standard license.
We recommend The Enterprise Plus license, because it allows you to enable the Distributed Resource Scheduler (DRS)
Along with this license, you must purchase a support subscription for at least one year.
A vCenter Server Standard license. Along with this license, you must purchase a support subscription for at least one year.
Hardware requirements
Google Distributed Cloud runs on a set of physical hosts that run the VMware ESXi hypervisor. To learn about the hardware requirements for ESXi, see ESXi Hardware Requirements.
By default, Google Distributed Cloud automatically creates Distributed Resource Scheduler (DRS) anti-affinity rules for your admin cluster and user cluster's nodes, causing them to be spread across at least three physical hosts in your datacenter.
This feature requires that your vSphere environment meets the following conditions:
VMware DRS is enabled. VMware DRS requires vSphere Enterprise Plus license edition.
Your vSphere user account has the
Host.Inventory.Modify cluster
privilege.There are at least three physical hosts available.
Recall that if you have a vSphere Standard license, you cannot enable DRS.
If you do not have DRS enabled, or if you do not have at least three hosts where
vSphere VMs can be scheduled, set antiAffinityGroups.enabled
to false
in
admin cluster
and
user cluster
configuration filess.
vCenter user account privileges
To set up a vSphere environment, an organization administrator might choose to use a vCenter user account that has the vCenter Server Administrator role. This role provides full access to all vSphere objects.
After the vSphere environment is set up, a cluster administrator can create admin clusters and user clusters. The cluster administrator does not need all the privileges provided by the vCenter Server Administrator role.
When a cluster administrator or developer creates a cluster, they provide a vCenter user account in a credentials configuration file. We recommend that the vCenter user account that is listed in a credentials configuration file be assigned one or more custom roles that have the minimum privileges required for cluster creation and management.
There are two different approaches an organization administrator can take:
Create several roles with varying degrees of privilege. Then create permissions that assign those limited roles to a user or group on individual vSphere objects.
Create one role that has all the needed privileges. Then create a global permission that assigns that role to a particular user or group on all objects in your vSphere hierarchies.
We recommend the first approach, because it limits access and increases the security of your vCenter Server environment. For more information, see Using Roles to Assign Privileges and Best Practices for Roles and Permissions
For information on using the second approach, see Create one global permission.
The following table shows four custom roles that an organization administrator can create. The administrator can then use the custom roles to assign permissions on specific vSphere objects:
Custom role | Privileges | Objects | Propagate to child objects? |
---|---|---|---|
ClusterEditor |
System.Read System.View System.Anonymous Host.Inventory.Modify cluster |
cluster | Yes |
SessionValidator |
System.Read System.View System.Anonymous Sessions.Validate session Cns.Searchable Profile-driven storage.Profile-driven storage view |
Root vCenter Server | No |
ReadOnly |
System.Read System.View System.Anonymous |
data center network |
Yes |
Anthos | Privileges in the Anthos role |
datastore resource pool VM folder network |
Yes |
Privileges in the Anthos custom role
Create custom roles and permissions
An organization administrator can use the govc command-line tool to create custom roles and permissions.
The organization administrator must have a vCenter Server account that has sufficient privileges for creating roles and permissions. For example, an account that has the Administrator role would be appropriate.
Before you run govc
, set some environment variables:
Set GOVC_URL to the URL of your instance of vCenter Server.
Set GOVC_USERNAME to the username of the organization administrator's vCenter Server account.
Set GOVC_PASSWORD to the password of the organization administrator's vCenter Server account.
For example:
export GOVC_URL=vc-01.example export GOVC_USERNAME=alice@vsphere.local export GOVC_PASSWORD=8ODQYHo2Yl@
Create custom roles
Create the ClusterEditor, SessionValidator, and ReadOnly custom roles:
govc role.create ClusterEditor System.Read System.View System.Anonymous Host.Inventory.EditCluster govc role.create SessionValidator System.Read System.View System.Anonymous Session.ValidateSessions Cns.Searchable StorageProfile.View govc role.create ReadOnly System.Read System.View System.Anonymous
Create a permission that grants the ClusterEditor role
A permissions takes a (user, role) pair and associates it with an object. When
you assign a permission on an object, you can specify whether the permission
propagates to child objects. With govc
, you do this by setting the
--propagate
flag to either true
or false
. The default is false
.
Create a permission that grants the ClusterEditor role to a user on a cluster object. This permission propagates to all child objects of the cluster object:
govc permissions.set -principal ACCOUNT \ -role ClusterEditor -propagate=true CLUSTER_PATH`
Replace the following:
ACCOUNT: the vCenter Server user account that is being granted the role
CLUSTER_PATH: the path of the cluster in the vSphere object hierarchy
For example, the following command creates a permission that associates the pair (bob@vsphere.local, ClusterEditor with my-dc/host/my-cluster. The permission propagates to all child objects of my-dc/host/my-cluster:
govc permissions.set -principal bob@vsphere.local \ -role ClusterEditor -propagate=true my-dc/host/my-cluster
Create additional permissions
This section gives examples of creating additional permissions. Replace the example object paths as needed for your environment.
Create a permission that grants the SessionValidator role to an account on the root vCenter Server object. This permission does not propagate to child objects:
govc permissions.set -principal ACCOUNT \ -role SessionValidator -propagate=false
Create permissions that grant the ReadOnly role to an account on a data center object and a network object. These permissions propagate to child objects:
govc permissions.set -principal ACCOUNT \ -role ReadOnly -propagate=true \ /my-dc \ /my-dc/network/my-net
Create permissions that grant the Anthos role to an account on four objects: a datastore, a VM folder, a resource pool, and a network. These permissions propagate to child objects:
govc permissions.set -principal ACCOUNT -role Anthos -propagate=true \ /my-dc/datastore/my-ds \ /my-dc/vm/my-folder \ /my-dc/host/my-cluster/Resources/my-rp \ /my-dc/network/my-net
Create one global permission
This section gives an alternative to creating several roles and several permissions. We do not recommend this approach because it grants a large set of privileges on all objects in your vSphere hierarchies.
If you have not already created the Anthos custom role, create it now.
Create one global permission:
govc permissions.set -principal ACCOUNT \ -role Anthos -propagate=true
Replace the following:
Replace ACCOUNT with the vCenter Server user account that is being granted the role
For example, the following command creates a global permission that grants the Anthos role to bob@vsphere.local. The permission propagates to all objects in your vSphere hierarchies:
govc permissions.set -principal bob@vsphere.local -role Anthos -propagate=true
Known issues
See Installer fails when creating vSphere datadisk.
What's next
CPU, RAM, and storage requirements