A private cloud is an isolated VMware stack (ESXi hosts, vCenter, vSAN, and NSX) environment managed by a vCenter Server in a management domain. Google Cloud VMware Engine deploys private clouds with the following VMware stack components:
- VMware ESXi: hypervisor on dedicated nodes
- VMware vCenter: centralized management of private cloud vSphere environment
- VMware vSAN: hyper-converged, software-defined storage platform
- VMware NSX Data Center: network virtualization and security software
- VMware HCX: application migration and workload rebalancing across data centers and clouds
You can retrieve generated sign-in credentials for VMware stack components from the private cloud details page.
VMware component versions
A private cloud VMware stack has the following software versions:
|ESXi||7.0 Update 2c||Enterprise Plus|
|vCenter||7.0 Update 2d||vCenter Standard|
|vSAN||7.0 Update 2c||Enterprise|
|NSX Data Center||3.1.2||Advanced|
When you create a private cloud, VMware ESXi is installed on provisioned Google Cloud VMware Engine nodes. ESXi provides the hypervisor for deploying workload virtual machines (VMs). Nodes provide hyper-converged infrastructure (compute and storage) and are a part of the vSphere cluster on your private cloud.
Each node has four physical network interfaces connected to the underlying network. Using two physical network interfaces, VMware Engine creates a vSphere distributed switch (VDS) on the vCenter. Using the other two interfaces, VMware Engine creates an NSX-managed virtual distributed switch (N-VDS). Network interfaces are configured in active-active mode for high availability.
vCenter Server Appliance
vCenter Server Appliance (VCSA) provides the authentication, management, and orchestration functions for VMware Engine. When you create and deploy your private cloud, VMware Engine deploys a VCSA with an embedded Platform Services Controller (PSC) on the vSphere cluster. Each private cloud has its own VCSA. Adding nodes to a private cloud adds nodes to the VCSA.
vCenter Single Sign-On
The embedded platform services controller on VCSA is associated with a vCenter Single Sign-On. The domain name is gve.local. To access vCenter, use the default user, CloudOwner@gve.local, which is created for you to access vCenter. You can add your on-premises/Active Directory identity sources for vCenter.
Private clouds have fully configured all-flash vSAN storage that's local to the cluster. At least three nodes of the same SKU are required to create a vSphere cluster with a vSAN datastore. Deduplication and compression are enabled on the vSAN datastore by default. Each node of the vSphere cluster has two disk groups. Each disk group contains one cache disk and three capacity disks.
vSAN storage policies
A vSAN storage policy defines the Failures to tolerate (FTT) and the Failure tolerance method. You can create new storage policies and apply them to VMs. To maintain SLA, you must maintain 25% spare capacity on the vSAN datastore.
On each vSphere cluster, there's a default vSAN storage policy that applies to the vSAN datastore. The storage policy determines how to provision and allocate VM storage objects within the datastore to guarantee a level of service.
The following table shows the default vSAN storage policy parameters:
|FTT||Failure tolerance method||Number of nodes in vSphere cluster|
|1||RAID 1 (mirroring)
Creates 2 copies
|3 and 4 nodes|
|2||RAID 1 (mirroring)
Creates 3 copies
|5 to 32 nodes|
Supported vSAN storage policies
The following table shows the supported vSAN storage policies and the minimum number of nodes required to enable the policy:
|FTT||Failure tolerance method||Minimum number of nodes required in vSphere cluster|
|1||RAID 1 (mirroring)||3|
|1||RAID 5 (erasure coding)||4|
|2||RAID 1 (mirroring)||5|
|2||RAID 6 (erasure coding)||6|
|3||RAID 1 (mirroring)||7|
NSX Data Center
NSX Data Center provides network virtualization, micro segmentation, and network security capabilities on your private cloud. You can configure all services supported by NSX Data Center on your private cloud by using NSX. When you create a private cloud, VMware Engine installs and configures the following NSX components:
- NSX-T Manager
- Transport Zones
- Host and Edge Uplink Profile
- Logical Switch for Edge Transport, Ext1, and Ext2
- IP Pool for ESXi Transport Node
- IP Pool for Edge Transport Node
- Edge Nodes
- DRS Anti-affinity rule for controller and Edge VMs
- Tier 0 Router
- Enable border gateway protocol (BGP) on Tier0 Router
VMware Engine handles initial installation, configuration, and monitoring of HCX in private clouds. You are responsible for lifecycle management of HCX Cloud and service appliances like HCX-IX Interconnect.
VMware provides updates for HCX Cloud through its HCX service. You can upgrade HCX Manager and deployed HCX service appliances from the HCX Cloud interface. To find the end of support date for a product release, refer to the VMware Product Lifecycle Matrix.
To ensure high availability of the private cloud, ESXi hosts are configured as a cluster. When you create a private cloud, VMware Engine deploys management components of vSphere on the first cluster. VMware Engine creates a resource pool for management components, and deploys all management VMs in this resource pool.
The first cluster cannot be deleted to shrink the private cloud. The vSphere
cluster uses vSphere HA to provide high availability for VMs. Failures to
tolerate (FTT) are based on the number of available nodes in the cluster. The
Number of nodes = 2N+1, where
N is the FTT, describes the
relationship between available nodes in a cluster and FTT.
vSphere cluster limits
|Minimum number of nodes to create a private cloud (first cluster)||3|
|Minimum number of nodes to create a cluster||3|
|Maximum number of nodes per cluster||32|
|Maximum number of nodes per private cloud||64|
|Maximum number of clusters per private cloud||21|
Guest operating system support
You can install a VM with any guest operating system supported by VMware for the ESXi version in your private cloud. For a list of supported guest operating systems, see the VMware Compatibility Guide for Guest OS.
VMware infrastructure maintenance
Occasionally it's necessary to make changes to the configuration of the VMware infrastructure. Currently, these intervals can occur every 1‑2 months, but the frequency is expected to decline over time. This type of maintenance can usually be done without interrupting normal usage of the services.
During a VMware maintenance interval, the following services continue to function without any effect:
- VMware management plane and applications
- vCenter access
- All networking and storage
- All cloud traffic
Updates and upgrades
Google is responsible for lifecycle management of VMware software (ESXi, vCenter, PSC, and NSX) in the private cloud.
Software updates include:
- Patches: security patches or bug fixes released by VMware
- Updates: minor version change of a VMware stack component
- Upgrades: major version change of a VMware stack component
Google tests a critical security patch as soon as it becomes available from VMware. Per SLA, Google rolls out the security patch to private cloud environments within a week.
Google provides quarterly maintenance updates to VMware software components. For a new major version of VMware software version, Google works with customers to coordinate a suitable maintenance window for upgrade.
- Learn about private cloud maintenance and updates