To understand this service, we first need to understand virtualization, VMware, and the problem that cloud migration creates.

Start with the virtual machine

A normal computer runs one operating system, such as Windows or Linux, and that system uses all of the machine. That wastes a lot. A big modern server may sit mostly idle if it runs only one small application. Virtualization fixes this. It lets one physical server pretend to be many smaller computers at the same time. Each pretend computer is called a virtual machine, or VM. Each VM has its own operating system, its own apps, and its own settings, yet all of them share the same physical hardware.

Meet VMware

VMware is a company that built some of the most popular virtualization software in the world. For more than twenty years, businesses have used its products to run their servers. A suite called VMware vSphere became the standard in many large organizations: banks, hospitals, factories, governments, and retailers. Because it is so common, there are huge numbers of trained administrators, backup tools, security tools, and monitoring tools that all expect a VMware environment.

The cloud migration problem

Now those same companies want to move to the cloud. They may want to close an aging data center, avoid buying new hardware, or reach new regions. But their applications were built for VMware. Moving them to a different cloud style usually means refactoring, which is a fancy word for rewriting parts of the app so it fits a new platform. That is slow, risky, and expensive. If you have thousands of VMs, it can take years.

The solution: VMware, run by Google, inside Google Cloud

Google Cloud VMware Engine is a managed service that gives you a full VMware environment running on dedicated hardware inside Google Cloud data centers. Google runs the hardware, the data center, the networking fabric, and the lifecycle of the VMware software. You get the same tools you already know, such as vCenter, and you connect them to Google Cloud services.

Google began offering this service after it acquired a company called CloudSimple, whose technology made this idea possible. The service became generally available in 2020 and has been adding regions and features since then.

The problems GCVE solves

• Data center exit deadlines. When a lease or hardware contract ends, you can move quickly without rewriting apps.
• Skills gap. Your VMware team keeps using the tools they already know.
• Risk. The VMs run the same way before and after the move, so there is less to go wrong.
• Capacity. You can add hosts in minutes instead of waiting weeks for new hardware to arrive.
• Disaster recovery. You can keep a second site in the cloud without building a second data center.

GCVE is built on VMware technology, so a few VMware words will appear again and again. Each one names a simple idea.

Three magic tricks of VMware

• vMotion: Moves a running VM from one host to another with no downtime. Users do not notice. It is like swapping the engine of a car while it is still driving on the highway.
• High Availability (HA): If a host crashes, the VMs that lived on it restart automatically on other hosts in the cluster.
• Distributed Resource Scheduler (DRS): Watches how busy each host is and moves VMs around to keep the load balanced, like a traffic officer sending cars to the emptier lanes.

More words you will meet

• Datastore: A storage space where VM files live.
• Snapshot: A saved picture of a VM at one moment, which you can return to if something goes wrong.
• Resource pool: A slice of a cluster’s CPU and memory reserved for a team or purpose.
• Storage policy: A rule that says how safely and how fast data should be stored, such as how many copies to keep.
• Segment: A virtual network in NSX where VMs connect, similar to a virtual room with its own address range.

A GCVE setup has a few clear layers: the Google Cloud building, the VMware engine network, the private cloud, and the links that connect them to everything else.

The private cloud

The main building block in GCVE is called a private cloud. This is not a vague idea. It is a real, dedicated VMware environment that contains:

• One or more clusters of ESXi hosts running on bare-metal servers.
• A vCenter Server to manage them.
• NSX to handle virtual networking and firewalls.
• vSAN to provide shared storage out of the local drives.
• HCX as an optional migration tool, usually installed to help move workloads.

Each private cloud is isolated. Nobody else shares its hosts, its storage, or its network. Many organizations create more than one private cloud, for example one for production and one for testing.

The VMware Engine network

Private clouds sit inside a special network called a VMware Engine network. Think of it as the private neighborhood where your private clouds live. From there, connections lead outward to your own Google Cloud network (called a VPC), to your on-premises data center, and to other services.

Connections to the outside

• Private connection to your VPC: Lets your VMware VMs talk to Google Cloud services privately, using internal addresses.
• Cloud VPN or Cloud Interconnect: Secure links between your on-premises data center and Google Cloud. VPN goes over the internet in an encrypted tunnel. Interconnect is a dedicated private line with higher and steadier speed.
• Internet access and public IPs: An optional service that lets VMs reach the internet or be reached from it, controlled by rules.

flowchart TB
  OnPrem["On-premises Data Center"] -->|"Cloud VPN or Interconnect"| GCNET["Google Cloud Network"]
  GCNET --> VEN
  subgraph VEN["VMware Engine Network"]
    subgraph PC["Private Cloud"]
      VC["vCenter Server"]
      NSX["NSX Networking and Firewall"]
      HCX["HCX Migration"]
      subgraph CL["Cluster of ESXi Hosts"]
        H1["Host 1"]
        H2["Host 2"]
        H3["Host 3"]
        VSAN["vSAN Shared Storage"]
      end
      VC --- CL
      NSX --- CL
      H1 --- VSAN
      H2 --- VSAN
      H3 --- VSAN
    end
  end
  VEN -->|"Private connection"| VPC["Your Google Cloud VPC"]
  VPC --> SVC["BigQuery, Cloud Storage, GKE and others"]
  VEN -->|"Optional"| NET["Internet via public IP service"]

Read the figure from the top. Your on-premises data center connects to Google Cloud through a secure link. Inside Google Cloud, the VMware Engine network holds your private cloud, where the cluster, vCenter, NSX, and vSAN live together. From there, a private connection reaches your normal Google Cloud network and the many services around it.

Who looks after what?

Sizing a GCVE environment means choosing how many hosts, what type, and how to arrange them.

What is a node?

In GCVE, a node is one dedicated physical server, also called a bare-metal host. Each node runs ESXi and contributes its processors, memory, and fast local drives to the cluster. At the time of writing, a common node type is called ve1-standard-72. It has around 72 logical processor cores, 768 gigabytes of memory, and several terabytes of fast NVMe storage. Newer and larger node types have been added over time, so always check the current list before you plan.

Cluster rules of thumb

• A normal production cluster begins with three nodes. Three is the smallest number that lets vSAN keep safe copies of data and survive a host failure.
• You can add nodes to grow a cluster, and remove them to shrink it, within limits Google publishes.
• Small trial environments with one or two nodes exist for testing, but they are limited in time and are not meant for real production.
• Each private cloud can hold several clusters, which is useful for separating different kinds of work.

Stretched clusters

A stretched cluster spreads one cluster across two zones inside the same Google Cloud region. A small extra helper called a witness sits in a third place and breaks ties. If one whole zone fails, the VMs restart in the other zone automatically, and the storage already has a copy of the data there. This provides a much higher level of protection than a single-zone cluster, at a higher cost, because you keep data and capacity in two places.

Sizing in practice

1. Collect facts. List your VMs and record the CPU, memory, and disk each one really uses, not just what it was given.
2. Add safety room. Leave spare capacity so that if a host fails, the others can absorb its VMs.
3. Consider storage. vSAN uses extra space to keep safe copies, so raw space is larger than usable space.
4. Pick a node count. Divide your needs by the capacity of one node and round up.
5. Plan for growth. Decide when and how you will add more hosts.

Let us follow what happens from the moment you decide to create a private cloud until your first VM runs.

Behind the simple button in the Google Cloud console, a long chain of automatic steps takes place. Google’s systems prepare physical servers, install the VMware software, connect everything, and hand you a ready environment. Understanding these steps helps you plan and troubleshoot.

Keeping the platform healthy

After creation, Google watches the platform constantly. If a host shows signs of failure, Google can replace it with a fresh node and rebalance the cluster. When VMware releases important updates, Google tests them and applies them on a planned schedule. Because the cluster has several hosts, updates are done one host at a time, using vMotion to move VMs out of the way first. Your workloads keep running through the process.

Two journeys are worth knowing: the life of a VM inside the private cloud, and the path a request travels from a user to an application.

The life of a VM

The journey of a user request

Imagine an employee opens a company expense app that runs on a VM in GCVE:

1. The employee’s device connects to the company network, either in an office or through a secure remote link.
2. The request travels over the private line, such as Cloud Interconnect or VPN, into Google Cloud.
3. It passes into the VMware Engine network and into the private cloud.
4. NSX checks its firewall rules and, if allowed, forwards the request to the right network segment.
5. The web VM receives it and asks a database VM on another segment for data. Distributed firewall rules check this internal call too.
6. The database VM reads its files from vSAN storage, which gathers the data from fast local drives across the cluster.
7. The answer returns along the same path to the employee.

Networking is the part that makes or breaks a migration, so we will take it slowly.

Two networking worlds that must meet

Inside a private cloud, NSX builds the networks. Outside it, Google Cloud VPC networks run the rest of your cloud estate. GCVE joins these two worlds so that traffic can pass between them privately and safely.

Key building blocks

• VMware Engine network: The regional or global network space that holds your private clouds and connects to your VPC.
• Private services access and VPC peering: A private link between your VPC and the VMware Engine network. Traffic stays on Google’s private network and never touches the public internet.
• NSX segments: Virtual networks inside the private cloud. VMs attach to segments and receive addresses from them.
• Tier-0 and Tier-1 gateways: Virtual routers. The tier-0 router faces the outside and the tier-1 routers serve groups of segments. Together they decide how traffic leaves and enters.
• Distributed firewall: A firewall that runs on every host and can protect VM-to-VM traffic even inside the same segment.
• DNS: VMs need name lookups. You can run your own DNS servers or forward lookups to Cloud DNS.

Reaching on-premises

For a migration, your old data center and the new private cloud must talk to each other. Cloud Interconnect gives a dedicated, fast, steady link and is the usual choice for large moves. Cloud VPN is a cheaper, encrypted alternative that is fine for small moves or as a backup path. Many teams use both, with Interconnect as the main road and VPN as the spare tire.

Stretching a network during migration

HCX can extend a network segment from on-premises into the private cloud. Machines on both sides then behave as if they share one network. This lets you move a VM without changing its IP address, which means no changes to firewalls, applications, or other systems that depend on that address. When the last VM has moved, you cut over the network and remove the extension.

Internet access

GCVE can provide internet access for VMs through a managed service, and you can assign public IP addresses to specific VMs when needed. Many designs instead send internet traffic through a central, well-protected path in Google Cloud, such as a firewall appliance or Cloud NAT, so that one place controls and logs all outside traffic.

Storage decides how fast your VMs feel and how safe your data is. GCVE gives you two main choices that can work together.

vSAN: storage built from the hosts themselves

Every GCVE node comes with fast local NVMe drives. vSAN takes the drives from all hosts in a cluster and joins them into one big shared pool called a vSAN datastore. VMs store their files in this pool, and they do not care which physical drive holds which piece.

The clever part is how vSAN keeps data safe. Instead of one copy, it stores several copies or pieces on different hosts. If one host or drive fails, the data is still available elsewhere. The rule that decides this is called a storage policy. A policy might say, “Keep two full copies so that one host can fail” or “Use a space-saving layout that survives two failures.” The number of failures a policy can survive is often called failures to tolerate.

Space-saving features

• Deduplication and compression: Remove repeated data and shrink what remains, so more fits in the same space.
• Erasure coding: A method that spreads data and protection pieces across hosts using less space than full copies, though it needs more hosts and more work.
• Encryption: vSAN data can be encrypted at rest. In GCVE you can use keys managed through Google Cloud’s key service if your rules require customer-controlled keys.

External datastores

One weakness of putting all storage inside the hosts is that storage and compute grow together. If you need more storage but not more processors, you still have to buy whole nodes. To fix this, GCVE supports external datastores, where VMs keep data on separate, managed storage services such as Google Cloud NetApp Volumes or Filestore, reached over the network. You can then grow storage on its own and often at lower cost. Fast, busy VMs can stay on vSAN, while large, calmer data sits on external storage.

flowchart TB
  VM1["VM: Database"] --> DS1["vSAN Datastore"]
  VM2["VM: Web Server"] --> DS1
  VM3["VM: File Server"] --> DS2["External Datastore"]
  VM4["VM: Archive"] --> DS2
  DS1 --> HOSTS["Local NVMe drives on all hosts in cluster"]
  DS2 --> EXT["Managed storage service in Google Cloud"]
  HOSTS --> POL["Storage policy: copies or erasure coding"]

Moving hundreds or thousands of VMs needs a plan, a tool, and good habits. The tool most people use is VMware HCX.

Step one: discover and assess

Before moving anything, learn what you have. Tools such as Google Cloud Migration Center, along with inventory exports from vCenter, can list every VM, how much it uses, what it talks to, and which ones depend on each other. This produces a map of applications and shows which servers must move together.

Step two: group into waves

You rarely move everything in one night. Instead, you group related systems into waves. A first wave is often small and low-risk, such as test servers, so the team can practice. Later waves handle more important applications.

Step three: choose a move method

sequenceDiagram
  participant Admin as Administrator
  participant OP as On-premises HCX
  participant Link as Secure Link
  participant CL as GCVE HCX
  participant PC as Private Cloud Cluster
  Admin->>OP: Select VMs and migration type
  OP->>Link: Pair sites and build service mesh
  Link->>CL: Encrypted tunnel ready
  OP->>CL: Replicate VM data
  CL->>PC: Write data to datastore
  Admin->>CL: Schedule switchover
  CL->>PC: Start VM in private cloud
  PC-->>Admin: VM is running, verify the application

Step four: validate and cut over

After each wave, test the applications. Check that users can sign in, jobs run, and reports match. Keep the old copy for a short while as a fallback. Once everything is verified, remove the old VM and, if you used network extension, switch the network over for good.

One of the biggest advantages of the cloud is that you can add capacity quickly. GCVE brings that advantage to VMware.

Scaling out and in

To get more power, you add nodes to a cluster. New hosts are prepared automatically, joined to the cluster, and added to the vSAN pool. This often takes a short time compared with weeks of ordering hardware. When demand falls, you can remove nodes and stop paying for them, as long as the remaining hosts have enough room for your VMs and data.

Autoscale policies

GCVE supports autoscale policies for clusters. You set rules based on measurements such as CPU use, memory use, and storage use. For example, “add a node when storage stays above seventy percent for a set time, and remove one when use drops below a lower level.” This reduces the need for someone to watch dashboards all day, and it prevents both shortages and waste. Always set sensible minimum and maximum node counts so that a spike cannot create a surprise bill.

Planning ahead

• Track trends. Watch CPU, memory, and storage over months, not days, to see real growth.
• Know the limits. Quotas limit the number of nodes per cluster, clusters per private cloud, and private clouds per project. Ask for increases before you need them.
• Use commitments wisely. Baseline capacity that always runs is a good candidate for a discounted commitment. Peaks can use on-demand nodes.
• Separate storage growth. If storage grows faster than compute, use external datastores instead of buying more nodes.
• Test failure room. Make sure the cluster can lose one host and still run everything.

A good design assumes something will fail. The goal is to keep running, or to recover fast, when it does.

Three levels of protection

Two numbers every architect should know

• RPO (Recovery Point Objective): How much data you can afford to lose, measured in time. An RPO of fifteen minutes means you accept losing at most the last fifteen minutes of work.
• RTO (Recovery Time Objective): How long you can afford to be down. An RTO of one hour means the service must be back within an hour.

Tighter numbers cost more, because they need more frequent copying and ready capacity. Match the numbers to what the business really needs.

Disaster recovery to another region or to the cloud

Many companies use GCVE as their disaster recovery site. VMs in their main data center are replicated to a small private cloud in Google Cloud. If the main site fails, the recovery plan powers on the copies in the cloud, and, if needed, the cluster is scaled out to full size. Because the recovery site only needs full power during a disaster, the daily cost stays low. Tools from VMware and from partners such as Zerto, Veeam, and others support this style of protection.

flowchart LR
  subgraph PRIMARY["Primary Site"]
    PVM["Production VMs"]
    PSAN["Primary Storage"]
    PVM --> PSAN
  end
  subgraph DR["GCVE Recovery Site in another region"]
    RVM["Standby VMs, powered off"]
    RSAN["Replica Storage"]
    RVM --> RSAN
  end
  PSAN -->|"Continuous replication"| RSAN
  FAIL["Disaster declared"] -->|"Run recovery plan"| RVM
  RVM --> USERS["Users reconnect"]

Backups are not the same as DR

Disaster recovery gets you running again after a site-level problem. A backup lets you go back in time, for example after someone deletes a file or ransomware scrambles your data. You need both. GCVE works with Google Cloud Backup and DR and with popular backup products from vendors such as Veeam, Commvault, and Cohesity. A good habit is to keep backups in a different place from the VMs, such as a Cloud Storage bucket, so one problem cannot destroy both.

Google publishes availability commitments for GCVE, and the figure differs between a single-zone setup and a stretched cluster. These numbers can change, so read the current service level agreement before you promise anything to your own customers.

Security works best in layers. GCVE gives you strong layers from Google and from VMware, and you add your own on top.

Physical and platform security

Your hosts are dedicated bare-metal servers, so no other customer shares them. This removes worries about noisy or untrusted neighbors. Google protects the data centers with guards, access control, and monitoring, and it keeps the hardware and VMware platform patched.

Access control

• Google Cloud IAM: Controls who can create, change, or delete private clouds and who can view their credentials in the console.
• vCenter roles: Control what people can do inside VMware, such as who can power on VMs or change networks. Use the principle of least privilege, which means giving only the permissions that are truly needed.
• Controlled elevated access: Because Google manages the platform, some very powerful rights are limited. When you need extra privileges for a task, there is a managed process to request them for a short time.
• Single sign-on: You can connect vCenter to your existing identity system, so people use their normal company login.

Network security

• NSX distributed firewall: Lets you write rules per VM or per group, called micro-segmentation. Even if an attacker enters one VM, they cannot freely wander to others.
• Private connections: Traffic to Google Cloud and to your data center stays on private links and encrypted tunnels.
• Central inspection: Many designs route traffic through a firewall or inspection point before it leaves for the internet.

Data protection

• Encryption at rest: vSAN encryption protects stored data, and you can bring customer-managed keys through Cloud KMS if you need to control them.
• Encryption in transit: Migration traffic and site links use encrypted tunnels.
• Immutable backups: Backups that cannot be changed or deleted for a set time protect against ransomware.

Auditing and compliance

Actions in the Google Cloud console are recorded in Cloud Audit Logs, and actions inside vCenter and NSX are logged by VMware. Forward these logs to a central place so security teams can search them. Google has compliance certifications that cover its cloud services, and many organizations pick GCVE partly to meet rules about where data lives. Always check which certifications apply to the specific region and service you plan to use.

After the move, day-to-day operations begin. You cannot fix what you cannot see, so good monitoring matters.

What to watch

Tools you can use

• Cloud Monitoring: GCVE sends key platform metrics here, where you can draw dashboards and set alerts alongside your other Google Cloud resources.
• Cloud Logging: A central place to collect logs from vCenter, NSX, and ESXi, together with Google Cloud audit logs.
• VMware tools: The built-in vCenter alarms and performance charts, and the VMware Aria Operations suite where you have it, provide deep VM-level detail.
• Third-party tools: Many existing monitoring products already know how to read VMware and keep working after the move.

Alerts that matter

Good alerts tell a person about real trouble, not every tiny blip. Tie alerts to goals such as “storage use above seventy-five percent for an hour” or “host failed”. Include a clear owner and next step in each alert so that whoever is on call knows what to do.

Maintenance and upgrades

Google schedules updates to the VMware software and the underlying hardware. You receive notice in advance and can plan around it. Because updates roll through hosts one at a time with vMotion keeping VMs running, most updates cause no visible outage. Still, keep your applications ready for restarts, and avoid sensitive times such as month-end processing.

Moving to GCVE is often the first step, not the last. Because your VMs sit next to Google Cloud services, you can improve them gradually.

Why the location matters

Your private cloud is connected to your Google Cloud VPC through a private, fast link. That means a VM in VMware can call a Google Cloud service with low delay and without crossing the public internet. You do not have to move everything at once. You can keep a legacy application where it is and add cloud-native pieces around it.

A simple modernization path

1. Rehost: Move the VM as is into GCVE and leave the data center.
2. Optimize: Right-size the VMs, use external storage, and clean up unused servers.
3. Integrate: Connect to Google Cloud services for analytics, backup, and monitoring.
4. Replatform: Swap parts, such as a self-run database, for managed services.
5. Refactor: Rebuild selected applications as containers or serverless services, one at a time.

The cloud is pay-as-you-go, but with dedicated hosts the way you buy matters a great deal.

What you pay for

• Nodes: The main cost. You pay for every dedicated host in your private clouds for every hour it exists, whether or not it is busy.
• VMware software: Historically the service price included the VMware licensing for the platform. Licensing arrangements across the industry have been changing, so check the current terms for what is included and what you must bring.
• Storage extras: External datastores and Cloud Storage are billed separately.
• Networking: Interconnect or VPN links, public IP addresses, and data that leaves Google Cloud or crosses regions can add up.
• Add-ons: Backup services, monitoring volume, and partner tools each carry their own prices.

Ways to buy nodes

Habits that save money

• Right-size first. Move VMs after measuring real use, so you do not pay for empty allocations.
• Clean up. Many data centers hold forgotten servers. Shut them down instead of migrating them.
• Use external storage. Grow storage separately instead of adding whole nodes just for disk space.
• Commit for the base, burst on demand. Cover your steady load with commitments and handle peaks with temporary nodes.
• Use autoscale limits. Prevent surprise growth by setting maximum nodes.
• Delete unused private clouds. Test environments left running over a weekend still bill by the hour.

Patterns are proven recipes. Anti-patterns are tempting shortcuts that hurt later.

Helpful patterns

Common anti-patterns

These habits come from many migrations that went smoothly and a few that did not.

Mistakes that surprise beginners

• Slow migrations. The link between sites is often the limit. Calculate how long the data takes to travel before you promise dates.
• Licensing surprises. Some software is priced by processor count or host. Moving to a new environment may change the cost, so check each vendor’s rules.
• Forgotten dependencies. An old server that quietly provides a file share or a scheduled job may be missed in discovery. Interview application owners, not just look at charts.
• DNS and time. VMs that cannot find a name server or have the wrong time can fail in strange ways after the move.
• Storage nearly full. Running vSAN at very high use leaves no room to rebuild after a failure, which can turn a small problem into a big one.
• Limits and quotas. Waiting until the last moment to ask for more nodes or addresses can delay a project.

These typical situations show how organizations use the service. They are patterns drawn from common practice, not reports about specific companies. Google publishes customer stories on its website if you want named examples.

Where it fits best

When to think twice

• If an application is already cloud-native or easy to move to containers, it may be cheaper to run it on Google Cloud directly.
• If you only have a handful of small VMs, dedicated hosts may be more than you need, and moving them to Compute Engine may be simpler.
• If your plan is to leave VMware completely in a few years, weigh the cost of staying on it in the meantime.

Quick answers to the questions people ask most.

You have now seen Google Cloud VMware Engine from the first virtual machine to a full modernization path. Here is the story in one place.