[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC)：2025-09-04。"],[],[],null,["# VMware Engine private clouds\n============================\n\nA Google Cloud VMware Engine private cloud is an isolated VMware stack that consists of\nthe following VMware components:\n\n- ESXi hosts\n- vCenter Server\n- vSAN\n- NSX\n- HCX\n\nPrivate clouds help you address a variety of common needs for network\ninfrastructure:\n\n- **Growth.** Add nodes with no new hardware investment when you reach a hardware refresh point for your existing infrastructure.\n- **Fast expansion.** Create additional capacity immediately when temporary or unplanned capacity needs arise.\n- **Increased protection.** Get automatic redundancy and availability protection when using a private cloud of three or more nodes.\n- **Long-term infrastructure needs.** Retire data centers and migrate to a cloud-based solution while remaining compatible with your enterprise operations. This is especially useful if your data centers are at capacity or you want to restructure to lower costs.\n\nVMware Engine nodes\n-------------------\n\nVMware Engine provides dedicated isolated bare metal hardware nodes to\ncreate VMware Engine private clouds. The nodes provide the compute,\nmemory, and storage required to run VMware ESXi, and are the basic unit of\nconsumption of VMware Engine. Using these nodes, you can create a vSphere\ncluster and run VMware VMs on the clusters.\n\nNode types\n----------\n\nThe following table lists key node types that are available when creating a\nVMware Engine private cloud. For all available node types and regions, see\n[VMware Engine nodes](/vmware-engine/docs/concepts-node-types). \n\n\n^\\*^ Raw storage, excluding cache, in terabytes. \n\n^†^ Available in select regions.\n\n\u003cbr /\u003e\n\nPrivate cloud environment\n-------------------------\n\nYou manage your private clouds through the Google Cloud console. Each private\ncloud has its own vCenter Server in its own management domain, and all nodes in\na given private cloud reside in the same region.\n\nThe VMware stack runs on dedicated, isolated bare metal hardware nodes in\nGoogle Cloud locations. You use the stack through built-in VMware tools,\nincluding vCenter Server and NSX Manager.\n\nPrivate clouds are also designed to eliminate single points of failure:\n\n- Clusters of ESXi hosts are configured with vSphere High Availability (HA) and sized to have at least one spare node for resilience. vSphere HA protects against node and network failures.\n- vSAN provides redundant primary storage. vSAN requires at least three nodes in a private cloud to provide protection against a single failure. You can configure vSAN to provide higher resilience for larger clusters.\n\nYou can connect the private cloud to your on-premises environment using the\nfollowing connections:\n\n- [Cloud VPN](/network-connectivity/docs/vpn)\n- [Cloud Interconnect](/network-connectivity/docs/interconnect)\n- [Point-to-site VPN](/vmware-engine/docs/networking/howto-vpn-connect)\n\n### Single-node private clouds\n\nFor pilot testing and proofs of concept with VMware Engine, you can\ncreate a private cloud that contains only a single node and cluster in any\nregion where VMware Engine is available. All VMware Engine\nfeatures are available in a single-node private cloud, but there are specific\nlimitations on VMware stack features due to cluster size.\n\nThe following are common use cases for a single-node private cloud:\n\n- **Proof of concept:** evaluating VMware Engine and its capabilities\n- **Disaster recovery testing:** deploying your application from recent backups to periodically validate disaster recovery preparedness\n- **Application upgrade testing:** test and validate application component upgrades before upgrading your application in production\n\nVMware Engine permits single-node private clouds without a time limit. However, single-node private clouds are not eligible for [SLA](/vmware-engine/sla) coverage. You can upgrade a single-node private cloud to a standard private cloud by expanding to\nat least 3 nodes. The expansion process won't disturb your VMs or\naccess to vCenter, and it initializes vSAN data replication after the nodes are\nsuccessfully added to the cluster.\n\nFor single-node private clouds, the default vSAN storage policy uses a Failures\nto Tolerate (FTT) value of FTT=0. When you expand a single-node private cloud,\nVMware Engine changes the default vSAN storage policy. The default\nvSAN storage policy changes to use FTT=1 for 3--4 node private clouds and to use\nFTT=2 for private clouds with at least 5 nodes.\n\nSingle-node private clouds are not upgraded with new software like a standard private cloud. You must delete and recreate single-node private clouds to obtain the latest software and security updates.\n\n### Custom core counts\n\nSome licensing agreements charge you based on the number of CPU cores on the\nunderlying physical node or in the cluster. Whenever you create a new cluster,\nyou can reduce the number of available cores for each node in the cluster to\nmeet the application license requirements. VMware Engine also creates\nany new nodes added to that cluster with the same number of cores per node,\nincluding when replacing a failed node. Confirm how the cores are counted\n(physically present or made available by BIOS) as stated in your contract to\nmanage licensing costs using this feature.\n\nCustom core counts are available for both the initial cluster as well as for any\nother clusters created in a private cloud. Reducing the number of available\ncores doesn't affect node pricing.\n\nLimitations\n-----------\n\nEach private cloud has resource limits for its nodes and clusters. Refer to\n[VMware in a private cloud](/vmware-engine/docs/concepts-vmware-components#vsphere-limits) for a list of\nthese limits.\n\n### Node limits\n\nWhen planning your VMware Engine resource needs, consider the number\nof nodes you need in your private cloud. The following table describes vSphere\ncluster limits in private clouds that meet [SLA](/vmware-engine/sla) requirements:\n\n### Private cloud limitations\n\nFor private clouds, the following limitations apply:\n\n- A private cloud cluster must have the same node type in the cluster.\n- A private cloud with clusters of different node types is not supported.\n\n### Single-node private cloud limitations\n\nFor single-node private clouds, the following limitations apply to the VMware\nstack:\n\n- Features or operations that require more than 1 node won't work. For example, you won't be able to use vSphere Distributed Resource Scheduler (DRS) or High Availability (HA).\n- The default vSAN storage policy uses FTT=0, so node failure results in data loss.\n\nAdditionally, the following VMware Engine limitations apply:\n\n- You cannot add a single-node cluster to an existing private cloud.\n- An existing private cloud cannot be converted to a single-node private cloud.\n- Node adjustments by autoscale policies aren't supported with a single-node private cloud.\n- VMware stack upgrades involve a downtime for your single-node private cloud.\n- VMware Engine doesn't encrypt data on vSAN on a single-node private cloud by default.\n- A private cloud must contain at least 3 nodes and complete vSAN data replication to be eligible for coverage based on the [SLA](/vmware-engine/sla).\n- You cannot adjust the number of cores per node with a single-node private cloud.\n\n### Custom core count limitations\n\nThe following limitations apply to a cluster that has a custom core count:\n\n- All nodes added to the cluster after initial creation also use the custom core count.\n- The number of cores per node can't be changed after cluster creation. To change the number of cores per nodes in the cluster, you must delete the cluster and create a new one.\n- The number of cores per node must be a multiple of 4 with a minimum of 8 (for example 8, 12, or 16).\n- Custom core counts aren't available for single-node private clouds.\n\nWhat's next\n-----------\n\n- Learn about [VLANs and subnets](/vmware-engine/docs/concepts-vlans-subnets)."]]
