Before going deep, we need a clear picture of the problem this service solves and what it actually delivers.

The world before the cloud move

For roughly two decades, a huge number of companies have run their business applications on virtual machines managed by VMware software. A virtual machine, often shortened to VM, is a software copy of a whole computer that runs on a shared physical server. VMware built the most widely used tools for creating, managing, protecting, and moving these virtual machines. Banks, hospitals, factories, retailers, and governments all keep thousands of such machines running in their own data centers.

Over time, these organizations face pressure to leave those data centers. Hardware gets old, leases end, buildings become expensive, and leadership wants the flexibility of the cloud. The difficulty is that moving an application to a cloud-native design usually means rewriting it, retesting it, and retraining the people who run it. For hundreds or thousands of applications, that can take years.

What the service gives you

Google Cloud VMware Engine is a fully managed service in which Google runs a complete VMware software environment on dedicated physical servers inside Google Cloud data centers. You receive your own isolated VMware environment, called a private cloud, built from real bare metal machines that no other customer shares. You manage your virtual machines with the same VMware tools your staff already knows, and Google handles the hardware, the data center, the network backbone, and the lifecycle of the underlying platform.

The core promise: lift and shift

The central idea is often called lift and shift. You lift your existing virtual machines out of your own data center and shift them into the cloud largely unchanged, keeping their addresses, their operating systems, and their configuration. Because the environment looks and behaves like the one you left, the application does not need a rewrite. Once the workloads sit next to Google Cloud services, you can modernize them gradually, one piece at a time, on a schedule that suits your business instead of a deadline forced by an expiring lease.

This service comes with its own vocabulary, a mix of VMware terms and Google Cloud terms. Here are the words you will hear constantly.

How the words fit together

Read the terms above from the bottom of the stack to the top. Physical nodes sit in a Google data center. ESXi turns each node into a host that can run virtual machines. A group of such hosts forms a cluster. vSAN pools their disks into shared storage, and NSX builds the virtual network that connects everything. vCenter sits on top as the control room where administrators work. All of this together, plus the dedicated hardware, is a private cloud.

Let us now build the picture layer by layer, from physical hardware up to the tools your administrators use every day.

The physical foundation

At the bottom are dedicated bare metal servers located in a Google Cloud region. They are connected by a high-speed internal network and placed inside Google’s data centers, which provide power, cooling, physical security, and the global fiber backbone. Because the servers are dedicated to you, your workloads do not compete for hardware with other customers. This is a major difference from typical public cloud virtual machines, and it is exactly what VMware software expects to find underneath it.

The VMware software stack

On top of the hardware runs the full VMware software-defined data center stack. ESXi virtualizes compute on each node. vSAN virtualizes storage across the cluster. NSX virtualizes networking. vCenter provides centralized management. Together they behave much like the environment in your own data center, which is why your existing skills and many of your existing tools continue to work.

The management layer

Each private cloud has a set of management components, including vCenter and the networking manager, that run as virtual machines inside the environment itself, on the first cluster. Google deploys, upgrades, and maintains these management components as part of the managed service. You receive credentials to log in and operate them for your own work, and you manage your virtual machines, folders, resource pools, policies, and so on, but you do not rebuild the platform itself.

flowchart TD
    A["Dedicated bare metal nodes in a Google Cloud region"] --> B["ESXi hypervisor on each node"]
    B --> C["vSAN pooled storage"]
    B --> D["NSX software-defined network"]
    C --> E["Cluster of hosts"]
    D --> E
    E --> F["vCenter management"]
    F --> G["Your virtual machines"]
        

The shared responsibility split

Where Google Cloud services fit

The big strategic benefit is that the private cloud sits right beside the rest of Google Cloud. Workloads can reach services such as Cloud Storage, BigQuery, Cloud SQL, and AI services over private, high-bandwidth connections, without crossing the public internet. That closeness is what makes gradual modernization practical: a legacy application can stay in its virtual machines while a new analytics feature next to it uses a cloud-native data service.

Since a node is the unit you buy, understanding node types is the key to understanding capacity and cost.

What a node provides

Each node contributes processing power, memory, and storage. In VMware terms, a virtual CPU is a logical thread of the physical processor, with two such threads for each physical core. When you add nodes to a cluster, all three resources grow together, because vSAN uses the local disks of each node as part of the shared storage pool.

Node families

Google Cloud offers several generations or families of node types, commonly referred to by names beginning with ve1 and ve2. The first family includes a standard node with a fixed combination of processing, memory, and storage. The second family offers a wider range of sizes, with variants that offer different balances of processors, large amounts of memory, and storage, and it also includes storage-only nodes. Exact figures, such as the number of virtual CPUs and the amount of memory per node, change as new hardware arrives, so always read the current node type documentation before you size a purchase.

Mixing node types

A cluster can combine hyperconverged nodes with storage-only nodes from the same family, but it cannot mix two different hyperconverged node types in the same cluster. A private cloud itself can contain clusters of different node types, which lets you create one cluster for general workloads and another tuned for memory-hungry or storage-heavy ones. Each cluster stays uniform, and the private cloud gains variety.

Sizing in practice

A private cloud can take several shapes. Choosing the right one depends on how much availability, cost, and flexibility you need.

The standard private cloud

The most common form is a standard private cloud, which lives within one zone of a region and contains at least a minimum number of nodes so the cluster can tolerate a node failure. It is a collection of vSphere clusters, the first of which hosts the management components, and you can add further clusters as your needs grow. A single private cloud supports a generous number of clusters, which is enough for large estates, though per-cloud limits exist and are documented.

Stretched private clouds

For workloads that must survive the loss of an entire zone, there is the stretched private cloud. It is spread across two data zones plus a third witness zone, all inside one region. Storage is mirrored between the two data zones, and the witness acts as a tiebreaker so the system can decide which side should keep running if the two zones lose contact with each other. Stretched clusters hold an equal number of nodes in each data zone, often written as three plus three or four plus four, so the minimum is an even number of nodes. Capacity changes are made in matching amounts on both sides.

flowchart LR
    subgraph ZA["Data zone A"]
        A1["Nodes A1 to A3"]
    end
    subgraph ZB["Data zone B"]
        B1["Nodes B1 to B3"]
    end
    subgraph ZW["Witness zone"]
        W["Witness node"]
    end
    A1 |"Mirrored storage and cluster traffic"| B1
    A1 --- W
    B1 --- W
        

Single-node private clouds

For testing, proofs of concept, or short evaluations, a single-node private cloud offers a low-cost way to try the service. It has no resilience, since one node is a single point of failure, and it is typically time limited and restricted in features. It is meant for learning and experimentation, not for production.

Comparing the shapes

Creation time and effort

Building a private cloud is not instant, because real hardware is prepared and the VMware stack is deployed on it. Standard environments commonly take a couple of hours to appear, and stretched environments can take somewhat longer, so build time into project plans instead of assuming the environment is ready minutes after you click create.

Networking is often the hardest part of a migration, because every address, route, and firewall rule has to line up. Understanding the building blocks makes it far more manageable.

The VMware Engine network

The VMware Engine network is a Google Cloud resource that acts as the networking hub for one or more private clouds. It handles connections between your private clouds, to Google Cloud virtual private cloud networks, and to your own on-premises networks, following a network policy you control. Think of it as the main junction where roads from several places meet.

Private IP planning

Careful address planning is critical. The address ranges used by the private cloud’s management and storage networks must not overlap with any other network that will talk to the private cloud, including your on-premises ranges and your Google Cloud virtual private cloud ranges. Overlapping ranges cause routing confusion that is painful to fix after the fact, so planning ranges early, and writing them down in one shared place, is one of the most valuable habits you can adopt.

Connecting to the rest of the world

flowchart LR
    ONP["On-premises data center"] -->|"Interconnect or VPN"| GC["Google Cloud network edge"]
    GC --> VEN["VMware Engine network"]
    VEN --> PC1["Private cloud"]
    VEN --> VPC["Google Cloud VPC"]
    VPC --> SVC["Cloud-native services"]
    VEN --> INT["Controlled internet egress"]
        

Software-defined networking inside

Inside the private cloud, NSX gives you segments, which are virtual networks that stand in for the VLANs of a physical data center. You can create segments for different applications or environments, define routing between them, and place distributed firewall rules directly at each virtual machine’s network card. Because these rules live in software, they follow a virtual machine wherever it moves, which is both powerful and a reason to keep rule sets tidy.

Name resolution

Applications find each other by name, so DNS must work smoothly across the private cloud, your on-premises network, and Google Cloud. A common design forwards queries for each environment’s names to the right DNS servers. Teams that overlook this discover, after a migration, that virtual machines start fine but cannot find the databases they need.

Storage in this service starts with vSAN and can be extended with options from Google Cloud itself.

How vSAN works

vSAN gathers the local disks inside every node of a cluster and presents them as one large, shared datastore. When a virtual machine writes data, vSAN stores it across several nodes according to a storage policy, so that the failure of a disk or an entire node does not lose the data. There is no separate storage array to buy, cable, or manage, and capacity grows as you add nodes.

Storage policies and failures to tolerate

A storage policy tells vSAN how much protection each virtual machine’s data needs. The key setting is how many failures to tolerate. A higher setting keeps more copies or more parity information and so survives more simultaneous failures, but it uses more raw space. Defaults are chosen to balance cost and safety based on the size of the cluster, with larger clusters generally getting stronger protection. You can create custom policies for particular workloads, for example giving a critical database stronger protection than a test server.

Encryption

vSAN data at rest is encrypted by default in these environments, using a key provider supplied by Google, and you can choose to use your own customer-managed encryption keys held in Google Cloud’s key management service if your compliance rules demand direct control. Encryption in transit between components is also part of the design. The practical lesson is that encryption is already on, so your effort goes into deciding who controls the keys, not into turning protection on.

Extending storage

Because storage and compute are bundled into nodes, a workload that needs huge amounts of data but modest processing can make clusters expensive. Two remedies exist. The first is storage-only nodes, which add capacity without extra compute. The second is attaching external storage from Google Cloud, such as managed file or block services reachable over a private connection and presented to the virtual machines as datastores or network shares. Which route is best depends on performance needs, since local vSAN is typically the fastest, and on cost, since external storage can be cheaper for colder data.

What actually happens behind the scenes when you request a private cloud, add a node, or lose a machine?

Provisioning a private cloud

Scaling out and in

Adding capacity means adding nodes to a cluster or creating a new cluster. The platform provisions new bare metal, joins it to the cluster, and vSAN rebalances data across the larger pool. Removing capacity does the reverse, safely evacuating data and virtual machines first. Because this is done by the managed service, scaling takes minutes to a short while rather than the weeks it takes to order, rack, and configure physical servers yourself.

Surviving a failed node

Servers fail. The platform expects this and handles it with two cooperating mechanisms. vSphere high availability notices the failed host and restarts its virtual machines on healthy hosts, which is why clusters are sized with at least one spare node. Meanwhile vSAN has stored extra copies of the data, so storage remains available and rebuilds protection onto remaining nodes. In many cases the platform can also replace a failed node automatically, restoring your original capacity without a ticket from you.

sequenceDiagram
    participant H as Failing host
    participant HA as vSphere HA
    participant V as vSAN
    participant P as Platform operations
    H-->>HA: Stops responding
    HA->>HA: Detect failure
    HA->>HA: Restart its VMs on healthy hosts
    V->>V: Serve data from remaining copies
    V->>V: Rebuild missing copies on other nodes
    P->>P: Provision replacement node
    P->>V: Join node and rebalance
        

Lifecycle and maintenance

Google maintains the underlying platform: it tests, schedules, and applies updates to the VMware software components it manages, and it coordinates the timing with notices to you. The process is designed so that virtual machines keep running, with vSphere moving them between hosts as individual nodes are updated. You still own your guest operating systems, so patch cycles for those remain on your calendar.

The true value of the service shows during migration. Following one virtual machine on its journey makes the moving parts clear.

The migration tools

The most common tool for moving virtual machines is VMware HCX, a mobility platform that connects your source environment to the destination private cloud. HCX creates secure, accelerated tunnels between sites and offers several movement styles. Google Cloud also offers its own migration tooling for bringing virtual machines in from various sources, and many organizations combine tools depending on the workload.

One virtual machine’s journey

flowchart TD
    A["Assess VM and dependencies"] --> B["Group into a migration wave"]
    B --> C["Extend network if keeping IP addresses"]
    C --> D["Replicate VM to the private cloud"]
    D --> E["Cutover during agreed window"]
    E --> F["Validate application health"]
    F --> G{"Healthy?"}
    G -->|"Yes"| H["Decommission source copy later"]
    G -->|"No"| I["Roll back to source"]
        

Why dependencies decide the order

Applications rarely live alone. A web server depends on an application server, which depends on a database, which depends on a directory service. If you move the web server alone, it may suffer terrible delay talking to a database that is still far away. Mapping these dependencies and moving connected systems together in the same wave avoids that painful, slow in-between state.

After the move

Migration is the beginning, not the end. Once machines are running in the private cloud, teams commonly right-size them, tune storage policies, consolidate old clusters, and start modernizing selectively. A database might move to a managed database service, a file server to a managed file service, or a reporting tool to a cloud analytics service, each time reducing the size of the VMware footprint.

Security is a partnership. Google protects the foundation, and you protect what you run on top of it.

Isolation by design

Each private cloud runs on dedicated bare metal, so there are no neighboring customers on the same physical servers. The environment is logically isolated in its own network space, and access is possible only through the connections you set up. This single-tenant design appeals strongly to organizations with strict isolation requirements.

Two layers of identity

There are two separate identity systems to manage, and confusing them is a frequent source of mistakes. The first is Google Cloud identity and access management, which controls who may create, view, change, or delete private clouds and related Google Cloud resources. The second is the identity system inside VMware, vCenter and NSX, which controls who may operate virtual machines and settings within the environment. Many organizations connect VMware’s identity system to their existing directory so that people use their normal accounts and so permissions follow job roles.

Microsegmentation

Traditional firewalls guard the edges of a network, which means that once an attacker is inside, movement between machines is often easy. NSX distributed firewalling enforces rules at every virtual machine, so even machines on the same segment can be forbidden from talking to each other unless a rule allows it. This approach, known as microsegmentation, limits how far a single compromise can spread. Designing rules by application role, instead of by individual IP address, keeps them understandable and easy to maintain.

Compliance and data location

Many regulated organizations choose this service because they can keep the same controls, evidence, and operating practices that their auditors already understand, while moving to a modern cloud provider. Data stays in the region you select, which helps with data residency rules. Google Cloud maintains a broad set of compliance certifications, but which ones apply to this particular service and to your own obligations must be confirmed in current documentation, because responsibility is shared and certifications do not automatically cover your applications.

High availability protects against small failures. Disaster recovery protects against big ones. Both are needed, and they are not the same thing.

The layers of protection

Protection comes in layers. Inside a cluster, vSphere high availability and vSAN storage policies handle node and disk failures. Across zones, a stretched private cloud handles the loss of a whole zone. Across regions, disaster recovery handles the loss of an entire location. And separate from all of these, backups protect against deletion, corruption, and ransomware, which replication alone cannot defend against because replication faithfully copies mistakes and damage too.

Disaster recovery options

A common pattern is to use a second private cloud in another region, with virtual machines replicated from the primary location on a schedule, and a documented plan to power them on if the primary is lost. Another popular pattern uses Google Cloud as the recovery site for on-premises VMware environments, so you pay for a small standby footprint instead of a full second data center, and expand it only when a disaster actually happens. VMware’s own replication and recovery tools, and partner backup products certified for the service, support these designs.

flowchart LR
    P["Primary private cloud in Region A"] -->|"Scheduled replication"| S["Recovery private cloud in Region B"]
    P -->|"Regular backups"| B["Isolated backup storage"]
    S -->|"Power on during disaster"| R["Recovered applications"]
    B -->|"Restore after deletion or ransomware"| R
        

Recovery objectives

Every protection design should start from two numbers agreed with the business. The recovery time objective states how long an application may be down. The recovery point objective states how much recent data the business can afford to lose. A strict objective means more frequent replication and more standby capacity, which means more cost. Stating the numbers openly turns a vague wish for safety into a concrete design with a clear price.

Running a private cloud well means seeing its health clearly, and in this service you can combine VMware’s tools with Google Cloud’s.

Two sources of truth

There are two layers to watch. The platform layer covers the hardware, the clusters, and the managed components, and Google Cloud provides visibility into the state of the service resources and sends notices about maintenance and events. The workload layer covers your virtual machines and applications, which you monitor with VMware’s tools such as the performance charts in vCenter and with the logging and monitoring products you already use.

Connecting to Google Cloud operations tools

Metrics and logs from the private cloud can be sent to Google Cloud’s monitoring and logging services, giving you dashboards and alerts alongside your other cloud workloads. This is especially helpful during gradual modernization, when one business application spans virtual machines in the private cloud and cloud-native components next door. A single view across both prevents finger-pointing between teams.

Capacity management

Capacity is the heartbeat of operations. Because you buy whole nodes, running a cluster too full risks being unable to survive a failure, while running it too empty wastes money. A healthy habit is to review utilization regularly, forecast growth from trends, and add or remove nodes ahead of need. Quick scaling is an advantage here, but only if you notice the trend in time.

Automation and infrastructure as code

Everything that can be done in the console can also be done through the service’s programming interfaces and command-line tools, and through infrastructure-as-code tools. Writing the creation of clusters, networks, and policies as repeatable definitions reduces errors, makes environments easy to reproduce for testing, and leaves a clear record of what changed and why. Inside the VMware layer, automation tools and scripts can similarly handle repetitive virtual machine tasks.

Cost is often the deciding factor, and the pricing model here is different from pay-per-second compute. Understanding it avoids bill shock.

You pay for nodes

The basic charge is per node, for every hour or period the node exists, regardless of how busy it is. This is quite different from paying only for the processing a small VM actually uses. Because nodes are dedicated hardware, an idle node costs the same as a busy one, which makes good utilization the main lever for efficiency. The price includes the VMware software licensing that is bundled into the service, which simplifies the bill compared with buying hardware, hypervisor licenses, and support separately.

Commitment discounts

Longer commitments reduce the price. Customers can choose on-demand usage with no commitment, or commit to terms such as one year or three years, paying monthly or upfront, in exchange for lower rates. The right choice depends on how stable your footprint is. A steady production base is a good fit for a commitment, while a temporary or uncertain footprint is better left on demand. Because pricing options and amounts change, always check the current pricing page and use the pricing calculator.

Where costs hide

No platform fits everything. The honest question is where this service shines and where another option is wiser.

Strong fits

Weaker fits

Choosing among options

Teams that succeed tend to repeat a few sound patterns. Teams that struggle tend to repeat a few avoidable mistakes.

Patterns worth adopting

Anti-patterns to avoid

A practical checklist, the traps that catch newcomers, and a few illustrative scenarios drawn from common industry patterns.

Best practices

Common mistakes

Real-world scenarios

What the scenarios share

Each success story began with planning the foundation, moved in measured waves, matched protection to business value, and treated the move as a stepping stone. None of them tried to do everything at once, and none left the environment unchanged forever.

Short, direct answers to questions that come up again and again.

No. Compute Engine runs virtual machines on Google’s own virtualization. VMware Engine runs genuine VMware software on dedicated bare metal, so your existing VMware tools, skills, and virtual machines carry over with little change.

Google manages the data center, the hardware, and the lifecycle of the managed platform components. You manage your virtual machines, guest operating systems, applications, security policies, and network design inside the environment.

Generally no. The purpose is to move virtual machines largely unchanged. You can modernize afterward at your own pace.

No. Nodes are dedicated bare metal servers used only by your private cloud, which is one reason the service suits strict isolation requirements.

Use a stretched private cloud, which spreads clusters across two data zones with a witness zone as a tiebreaker. For loss of a whole region, add disaster recovery to another region.

Much faster than buying hardware, because the platform provisions bare metal and joins it to your cluster for you. Exact times vary, so check current documentation and plan ahead for large expansions.

Use network extension through the migration tooling so a segment appears in both places, and moved machines keep their addresses. Retire the extension after the whole segment has moved.

Yes. The private cloud connects privately to Google Cloud networks, so your virtual machines can use storage, databases, analytics, and other services with low latency and without crossing the public internet.

Data at rest on vSAN is encrypted by default, and you can choose customer-managed keys if you need direct key control. You should also encrypt traffic between your own components according to your policy.

Mainly per node, with discounts for one-year and three-year commitments. Idle nodes still cost full price, so utilization matters. Confirm current rates and terms on the official pricing page.

A single-node private cloud is intended for evaluation and testing. It has no resilience and is not meant for production, but it is a low-risk way to learn the service.

Usually not. New applications are normally better built on cloud-native services such as containers or serverless platforms. This service shines for existing VMware workloads.

Yes. Replication copies damage as quickly as it copies good data. Independent, versioned, isolated backups protect against deletion, corruption, and ransomware.

Google Cloud VMware Engine gives organizations a way to carry their existing VMware estate into Google Cloud without rewriting applications. Dedicated bare metal nodes, grouped into clusters inside a private cloud, run the familiar VMware stack of ESXi, vSAN, NSX, and vCenter, while Google operates the data center, the hardware, and the platform lifecycle. A VMware Engine network ties private clouds to Google Cloud and to on-premises sites, and careful address and name planning keeps that connectivity smooth. Resilience comes in layers: vSphere high availability and vSAN policies for nodes, stretched private clouds for zones, cross-region recovery for disasters, and independent backups for damage. Security is shared, with Google protecting the foundation and you protecting identities, networks, guest systems, and data. Because you pay for whole nodes, utilization, right-sizing, and a steady modernization roadmap decide whether the service is economical. Used well, it buys time: a safe, fast first step that lets you move on a deadline and then modernize on your own terms.