A fully managed service that lets you run the VMware platform inside Google Cloud.

First, what is VMware?

A physical server is a powerful computer, but most applications use only a small part of its power. Virtualization solves this waste by letting one physical server pretend to be many smaller computers, each called a virtual machine, or VM. Each VM has its own operating system and applications, completely separate from its neighbors. VMware is the company whose software made this idea mainstream in company data centers, and its products are used by a very large share of big organizations around the world.

What the service gives you

Google Cloud VMware Engine, often shortened to GCVE, delivers a complete VMware environment running on dedicated, isolated bare metal hardware inside Google Cloud data centers. Bare metal means the physical servers are not shared with any other customer. You receive the familiar VMware tools, including vSphere, vCenter, vSAN, NSX and HCX, so your administrators keep their skills, scripts and processes.

The key promise is migration without refactoring. Refactoring means rewriting an application so that it fits a new platform, which is slow, risky and expensive. With VMware Engine, a virtual machine that runs in your data center today can usually run in the cloud tomorrow in the same form.

The business reasons behind moving a VMware estate to Google Cloud.

Large companies often own hundreds or thousands of VMware virtual machines that were built over many years. Moving them one by one to native cloud services would take years of engineering work. The pressures that push companies toward VMware Engine are usually practical rather than technical.

Ten words you will meet in every VMware Engine conversation.

You do not need to memorize these now. Each one gets its own explanation in later chapters, and seeing how they connect makes them easy to remember.

What a private cloud is made of, from hardware up to the management console.

A private cloud is an isolated VMware stack. At the bottom are dedicated bare metal nodes in a Google Cloud location. On each node runs ESXi. A set of nodes forms a vSphere cluster, and the local drives inside those nodes are pooled by vSAN into one datastore. NSX sits across the cluster providing virtual networking and security. A vCenter Server, deployed for you at creation, manages the whole group. HCX is added to help with migration.

flowchart TD
GC["Google Cloud Console and APIs"] --> PC["Private Cloud"]
PC --> VC["vCenter Server"]
PC --> NSX["NSX Manager"]
PC --> HCX["HCX Manager"]
PC --> CL["vSphere Cluster"]
CL --> N1["Node 1 with ESXi"]
CL --> N2["Node 2 with ESXi"]
CL --> N3["Node 3 with ESXi"]
N1 --> VS["vSAN Shared Datastore"]
N2 --> VS
N3 --> VS
VS --> VM["Your Virtual Machines"]
        

Dedicated, not shared

The hardware is dedicated and isolated. Your nodes are not carved up among strangers. This is what gives VMware workloads the predictable performance and strict separation that many companies expect. Each private cloud has its own vCenter in its own management domain, and all nodes of a standard private cloud sit together in one location.

Who manages what

Google runs the physical infrastructure and the lifecycle of the VMware software stack, including hardware replacement, patching and upgrades of the platform components. You remain responsible for everything inside your virtual machines, such as the guest operating systems, applications, backups of your workloads, user access and the way you design your networks.

Nodes are the building bricks, and clusters are the walls you build from them.

What a node provides

A node bundles processing cores, memory and fast flash storage. A commonly cited example node type offers 72 virtual processors, 768 GiB of memory and about 19.2 TB of raw storage. Newer node families offer other shapes, including options with more memory per node, so you can match the hardware to the workload. Check the official node type list for what is available in your region.

Size limits to remember

A standard private cloud needs at least three nodes in its first cluster, and each cluster needs at least three nodes. A cluster can grow up to 32 nodes, and a private cloud can grow to 96 nodes in total. These numbers matter when planning because very large estates may need several clusters.

Rules about mixing

Every node in one cluster must be the same type, so a cluster cannot mix two different compute node types. Within a cluster you may add storage-only nodes of the same family to compute nodes. A private cloud itself can hold clusters from different node families. You can also choose a custom core count per node, in steps of four with a minimum of eight, which lets you reduce the number of processor cores you pay for when licensing is counted by core. That setting is fixed when a cluster is created.

How the local drives inside every node become one shared and protected storage pool.

vSAN is hyper-converged storage. Hyper-converged means compute and storage live inside the same servers rather than in a separate storage box. Each node contains fast flash drives, arranged as two disk groups per node, with each group using a cache drive and several capacity drives. All the drives of all nodes are combined by vSAN into a single datastore that virtual machines use.

Failures to tolerate

The strength of protection is set by a policy called Failures to Tolerate, or FTT. FTT equal to one means the data survives the loss of one node, and FTT equal to two means it survives two. The default policy depends on cluster size: smaller clusters of three or four nodes use FTT of one, and clusters of five or more nodes use FTT of two. Mirroring keeps full extra copies, while erasure coding saves space by storing data and parity pieces, but it needs more nodes.

Space efficiency and encryption

Compression is turned on by default for the vSAN datastore of new clusters, and deduplication, which removes repeated data, can add savings. Data on the datastore is encrypted for standard private clouds, while single-node private clouds do not encrypt vSAN data by default.

Adding more storage

When capacity runs short you have choices. You can add whole nodes, add storage-only nodes, or attach external storage services supported with the platform. The right choice depends on whether you are also short on compute.

How your private cloud talks to your data center, to Google services and to the internet.

Networking is the part of a VMware Engine project that most often decides success or delay. A private cloud lives in its own network space, so you must plan address ranges and connections carefully before creating anything.

Address planning

When you create a private cloud you reserve a block of private addresses for its management network, which holds vCenter, vSAN and other management parts. This block must not overlap with any address range used elsewhere, such as in your data center or Google Cloud networks. Overlapping ranges are one of the most common causes of painful rework, because the ranges cannot simply be changed later.

Connection paths

flowchart LR
OP["On-premises Data Center"] -->|"VPN or Interconnect"| VPC["Google Cloud VPC"]
VPC -->|"Private connection"| PC["VMware Engine Private Cloud"]
PC --> SEG["NSX Segments"]
SEG --> VMS["Virtual Machines"]
VPC --> GS["Google Cloud Services"]
        

DNS and name resolution

Names matter as much as addresses. Virtual machines must find each other and Google Cloud services by name. Plan where name lookups are answered, and make sure both your data center and the cloud can resolve each other’s names.

Build switches, routers and firewalls as software, and place a guard at every virtual door.

NSX turns networking into software. Instead of cables and boxes, you define segments, gateways, routing and firewall rules in a console. A segment is a virtual network where machines can talk directly. A gateway connects segments to each other and to the outside. Because everything is software, a new network takes minutes, not days.

Micro-segmentation

Traditional firewalls guard the edge of a network, so once an attacker is inside, they can often move freely. Micro-segmentation puts a firewall around each individual virtual machine. Rules say which machines may talk to which others, and everything else is blocked. If one machine is attacked, the damage stays contained.

The moving trucks of VMware Engine, and the different ways they can carry your machines.

HCX is a hybrid cloud mobility toolkit. It connects your existing VMware environment with the private cloud and offers several migration styles. It can also stretch a network so that a moved virtual machine keeps its original address, which removes the need to change application settings.

flowchart TD
A["Assess and group workloads"] --> B["Build landing zone and network"]
B --> C["Connect HCX between sites"]
C --> D["Pilot migration of low risk waves"]
D --> E["Migrate in planned waves"]
E --> F["Validate and cut over"]
F --> G["Decommission old hardware"]
        

Thinking in waves

Large migrations are never done in one move. Applications are grouped into waves, usually starting with low risk systems to build confidence. Applications that depend on each other must move together, otherwise slow network links between split halves cause performance trouble.

Surviving the loss of an entire data center zone without losing your applications.

A normal private cloud lives in one zone. A zone is one independent failure area inside a Google Cloud region, such as a separate building. If that zone goes down, everything in the private cloud goes with it. A stretched private cloud solves this by spreading one cluster across two zones, with a third zone holding a small witness node.

flowchart LR
subgraph ZA["Zone A"]
A1["Data Node"]
A2["Data Node"]
A3["Data Node"]
end
subgraph ZB["Zone B"]
B1["Data Node"]
B2["Data Node"]
B3["Data Node"]
end
subgraph ZC["Zone C"]
W["Witness Node"]
end
ZA |"Synchronous replication"| ZB
W -.-> ZA
W -.-> ZB
        

How it works

Data is written to both data zones, so each zone holds a full copy. The witness is a tie-breaker. If the two zones lose contact with each other, the witness decides which side keeps running, which prevents both sides from believing they are in charge. A stretched cluster must have an equal number of nodes in each data zone, starting at three plus three, so six nodes in total, and growing up to sixteen plus sixteen.

What happens from the moment you click Create until your first virtual machine runs.

Lifecycle and maintenance

Over time the platform software receives updates. Google plans and performs these for the infrastructure and core VMware components, aiming to keep virtual machines running while hosts are updated one at a time. Because maintenance relies on free capacity in the cluster to move machines around, running clusters at full capacity makes maintenance harder.

Failed hardware

If a node fails, the platform can automatically replace it, and vSAN rebuilds the missing data copies on the new node. New nodes are created with the same settings as the others, including the custom core count if you chose one.

Sitting next to Google Cloud lets VMware workloads borrow powerful services.

One of the biggest benefits is proximity. Your virtual machines are connected over a private, high speed path to Google Cloud services. That lets you improve applications gradually without leaving the VMware environment all at once.

Layers of protection from the physical building up to each virtual machine.

The shared responsibility idea

Google secures the physical facilities, the hardware and the underlying platform. You secure your workloads, your data, your network rules and your accounts. Knowing exactly where the line sits prevents gaps that nobody owns.

Two worlds of access

There are two separate areas of access control. The first is Google Cloud itself, where identity and access management decides who can create, resize or delete private clouds. The second is VMware, where roles in vCenter and NSX decide who can create machines, change networks or edit firewall rules. Both need careful design, and each should follow the principle of least privilege, meaning each person gets only the access the job requires.

Protecting the data

Data stored on the vSAN datastore of standard private clouds is encrypted. Network traffic between your data center and the cloud should travel over encrypted tunnels or private dedicated connections. For sensitive data you can add your own key management so that you control the encryption keys.

Knowing how the platform is doing, and being able to recover when something goes wrong.

Monitoring

Watch the health of the platform and the workloads. Key signals include processor and memory pressure per cluster, vSAN capacity and health, network throughput on the connection to your data center, and alerts raised by the platform. Combine VMware monitoring tools with Google Cloud monitoring so that one team sees one story.

Backup

Redundancy is not backup. vSAN protects against hardware failure, but if someone deletes a virtual machine or a virus encrypts the data, every copy is affected. You still need backups stored separately, tested regularly and kept long enough to meet business and legal needs. Backup partners provide tools for VMware environments, and cloud object storage is a common low cost target.

Disaster recovery

Two numbers define recovery goals. The recovery time objective is how long the business can stand to be down. The recovery point objective is how much recent data it can afford to lose. A stretched cluster gives very low values within a region, while replicating to another region or to a separate recovery private cloud protects against larger disasters.

You pay by the node, so the node count is the main lever on your bill.

VMware Engine is priced per node, per hour, and nodes are dedicated bare metal servers, so the cost model is closer to renting servers than to paying per virtual machine. Commitment options exist, such as one year or three year terms, which lower the hourly price in return for a promise to keep the capacity. Licensing arrangements for the VMware software have changed in the industry over the last few years, so check the current Google Cloud pricing page and licensing terms before you commit to any budget.

What makes up the total

Where VMware Engine fits best across different industries.

The service is used by organizations that rely heavily on VMware and have a strong reason to move quickly. The scenarios below are common patterns rather than named customer stories, because architectures and contracts change.

Speed and familiarity are bought with higher unit cost and less cloud-native freedom.

Habits that make VMware Engine projects succeed, and habits that sink them.

Patterns that work

Successful teams build a landing zone first, with network, identity, logging and security ready before any workload arrives. They migrate in waves and keep dependent applications together. They use clusters sized with spare capacity. They treat the private cloud as a stepping stone and keep a modernization backlog, moving components to managed Google Cloud services where the benefit is clear. They automate repeated tasks such as creating networks, using infrastructure as code.

A checklist to keep your migration smooth, secure and affordable.

Mistakes beginners make most often

The first is underestimating network planning and overlapping address ranges. The second is moving applications piece by piece without regard to dependencies. The third is sizing by raw capacity rather than by usable capacity after storage policies. The fourth is forgetting guest software licenses when estimating cost. The fifth is assuming that managed means no operations work remains.

Choosing between keeping VMware, converting machines, or rebuilding applications.

VMware Engine is one of several ways to move to Google Cloud. The best choice often differs from application to application, and many companies use a mix.

flowchart TD
Q1{"Is the deadline very tight or estate very large?"} -->|Yes| VE["VMware Engine"]
Q1 -->|No| Q2{"Can the app run on standard cloud VMs?"}
Q2 -->|Yes| CE["Compute Engine"]
Q2 -->|No| Q3{"Worth modernizing now?"}
Q3 -->|Yes| MOD["Containers or managed services"]
Q3 -->|No| VE
        

Other major cloud providers offer similar managed VMware services, so the idea is not unique to Google. The practical differences lie in each provider’s regions, networking, pricing and the services available next door. Compare them against your own needs rather than in general.

Usually not. The environment is built to be compatible with existing VMware virtual machines, which is its main value. You still need to test each application after the move, particularly for networking and performance.

Google manages the infrastructure and the lifecycle of the core platform software, while you manage virtual machines, guest software, networks and access policies inside the environment.

A standard private cloud covered by the service level agreement needs at least three nodes. A stretched private cloud needs at least six, split evenly between two zones. A single node is possible for testing but is not covered by the SLA.

No. Nodes are dedicated bare metal servers, and the private cloud is isolated for your use.

Yes. Administrators use the familiar vCenter client and NSX console, and many existing automation scripts and third party tools continue to work, although some settings that Google manages are restricted.

Through Cloud VPN for an encrypted internet tunnel, or Cloud Interconnect for a dedicated private line. Large migrations usually favor Interconnect for its capacity and consistency.

Yes, by using HCX network extension, which stretches your on-premises network into the cloud. Later you can re-address machines at your own pace.

vSAN keeps extra copies of data, so virtual machines continue to run, and the platform replaces failed hardware. A larger cluster and a higher failures-to-tolerate policy increase the protection.

You can grow clusters by adding nodes, and you can shrink them where policies and capacity allow, keeping within the minimum cluster size. Commitment terms may affect how freely you can reduce spending.

No. They solve different problems. Compute Engine runs standard cloud virtual machines, while VMware Engine runs the full VMware stack for workloads that must stay in that format. Many companies use both side by side.

It depends on utilization, hardware refresh cycles, power, staffing and licensing. It can be cheaper when it avoids a hardware purchase or lets you close a facility, and more expensive for steady, well utilized systems. Always build a full cost comparison.

It can be, but many organizations treat it as a first step. After the move, they modernize selected workloads to run on native cloud services over time.

Google Cloud VMware Engine gives companies a fast and low-risk way to move VMware workloads to Google Cloud. You get a dedicated private cloud made of bare metal nodes running vSphere, vCenter, vSAN, NSX and HCX, managed by Google at the platform level while you keep the tools and skills you already have. Success depends on careful network planning, right-sized clusters with spare capacity, wave based migrations, strong security layers, tested backups and a clear plan for what comes after the move.