Migrate for Compute

Engine

Tad Einstein

Welcome to the Migrate for Compute Engine module, where we will introduce how to
use the Google Cloud’s virtual machine migration tool.
 Google’s VM migration process

Assess Prepare Migrate Optimize

Evaluate your Understand the Move virtual Tune your
environment platform machines operations and
save on costs

So far in the course, you’ve learned how to discover your source environment and
find eligible virtual machines to migrate to the cloud. You then learned the
fundamentals of the destination environment, Google Cloud. Building on top of that
foundational knowledge, I will introduce how to migrate virtual machines from your
source environment to Google Cloud.
 Learn how to...
Understand Migrate for Compute
Engine’s architecture
Install Migrate for Compute Engine
in your source environment
Understand the migration process
Use special features
Migrate groups of VMs

In this module, you will learn about Migrate for Compute Engine architecture, how to
install it in your source environment, the migration process, and using special features
like running a test clone and migrating groups of VMs.
 Agenda
Migrate for Compute Engine
Migration Technical Architecture
Installation Process
Migration Process
Lab: Migrating to Compute Engine
Additional Features
Migration Wave
Migrating from VMware

The lessons in this module cover the Migrate for Compute Engine main features -
including the migration technical architecture, installation process, migration process,
and some additional features.

There is a lesson that covers migration waves - and how to use them to migrate
multiple VMs.

And finally, there is a lesson that covers how to migrate from VMware. There are
some additional features available when migrating from VMware using Migrate for
Compute Engine 5 - and these features are covered in the lesson. Let’s begin.
 Agenda
Migrate for Compute Engine
Migration Technical Architecture
Installation Process
Migration Process
Lab: Migrating to Compute Engine
Additional Features
Migration Wave
Migrating from VMware

In this module, you will learn about the Migrate for Compute Engine main features.
 Migrate for Compute Engine

Minimal Downtime
VM

VM VM
On
Premise
Streaming

On Premises Google Cloud

With Migrate for Compute Engine’s real-time streaming, stateful workloads begin
running in the cloud within minutes, instead of days or weeks. Applications begin
running in Google Cloud after just a few minutes, so there's negligible downtime.
Meanwhile, remaining data transfers seamlessly in the background — in a way that is
completely transparent to end users. This helps maintain SLAs, while keeping
maintenance windows short and predictable.
 Migrate for Compute Engine

Reduce Risk

Built-in testing makes it fast and easy to validate before you migrate, and fast
rollbacks to on-premises provide a safety net when the unexpected happens.
 Migrate for Compute Engine

Rightsize
Recommendations

Lastly, When you are ready to migrate your virtual machine, Migrate for Compute
Engine provides you with data-driven rightsizing recommendations to optimize both
cost and performance. Since you pay for what you allocate in the cloud rather than
what you use, choosing the right size for your virtual machine can save you from over
provisioning and therefore optimize your spend.
 Agenda
Migrate for Compute Engine
Migration Technical Architecture
Installation Process
Migration Process
Lab: Migrating to Compute Engine
Additional Features
Migration Wave
Migrating from VMware

In this lesson, we will cover the main components of Migrate for Compute Engine and
how they work together.
 Migrate for Compute Engine
● AWS and Azure use a similar migration
architecture (Migrate for Compute Engine 4.x).
● VMware uses a different migration architecture
(Migrate for Compute Engine 5.x).
○ VMware migrations and the VMware migration
architecture are covered in the last part of this
lecture.

AWS and Azure use a similar migration architecture. To migrate from AWS or Azure,
use Migrate for Compute Engine 4.x. The first part of this lecture covers migration
from AWS and Azure.

To migrate from VMware, you can use Migrate for Compute Engine 5.x, which offers
some additional features. The last part of this lecture covers migration from VMware.
 AWS Importer

VPC
Migrate for Compute
Engine Manager
AWS EC2 VMs
Migrate for Compute
Engine Importer
Cloud VPN Migrate for Compute Engine Cloud Extension
z

Zone: us east1-a Zone: us east1-a

EC2 Virtual Machine

Edge Node A Edge Node B

If your source environment is AWS, a Migrate for Compute Engine Importer virtual
machine will be installed automatically in your AWS cloud environment, which
provides the same functionality as the Backend on premises. Everytime a migration is
initiated, the Manager creates an Importer in your AWS environment to stream the
source virtual machine disk to Google Cloud over a secure connection. When the
migration is completed, the Importer is deleted.
AWS EC2 VMs Migrate for Compute
Engine Manager
Migrate for Compute
Engine Importer
Cloud VPN Migrate for Compute Engine Cloud Extension

EC2 Virtual Machine

z Zone: us east1-a

Edge Node A
 Cloud Extension
AWS EC2 VMs

On-Premises VMs VPC

Migrate for Compute
Local Compute Engine Manager

Migrate for Compute Migrate for Compute Engine Cloud Extension

Engine Importer

z Zone: us east1-a Zone: us east1-a

Cloud VPN Edge Node A Edge Node B

MIgrate for Compute

Migrated VMs
Engine Importer

Local Compute

On-Premises VMs

Azure VMs

vSphere

The receiving
On-Premises VMs
end of thevCenter
Importer
Server
from AWS or the Backend from your on premises
Migrate for Compute
infrastructure is the Cloud Extension.
Local Compute
Engine vCenter PluginThe Cloud Extension is hosted in Google Cloud.

It helps to Migrate
create a highly optimized data streaming and caching layer for the VMs
for Compute
Engine Backend
which are being migrated to the Cloud, thus reducing VPC
downtime to minutes. The Cloud
Extension is composed of a pair of Cloud Edge nodes for redundancy, one in each
Migrate for Compute
Engine Manager
zone. They serve data to the migrated virtual machine over an iSCSI interface.
Cloud VPN Migrate for Compute Engine Cloud Extension

z Zone: us east1-a Zone: us east1-a

Edge Node A Edge Node B

Migrated VMs
 Agenda
Migrate for Compute Engine
Migration Technical Architecture
Installation Process
Migration Process
Lab: Migrating to Compute Engine
Additional Features
Migration Wave
Migrating from VMware

In this video, you will learn how to install Migrate for Compute Engine in Google Cloud
and your source environment, either on-premises or in AWS.
 1 Setup VPN + Network tags

To deploy Migrate for Compute Engine 4.x infrastructure, you will need to go through
a few steps. Migrate for Compute Engine uses a secure VPN tunnel or Interconnect to
connect your source environment and requires specific networking rules to be set up
before migrations can begin.
 1 Setup VPN + Network tags

2 Create Google Cloud roles and service

accounts

After the network is set up, you'll need to create Google Cloud roles and service
accounts that Migrate for Compute Engine can use to create Google Cloud resources
and manage the Cloud Storage API. Migrate for Compute Engine includes a Cloud
Shell script for making these changes.
 1 Setup VPN + Network tags

2 Create Google Cloud roles and service

accounts

3 Deploy Migrate for Compute Engine Manager

Once your Google Cloud project is configured properly, you can deploy the Migrate for
Compute Engine Manager from the Google Cloud’s Marketplace in just a few clicks.
 1 Setup VPN + Network tags

2 Create Google Cloud roles and service

accounts

3 Deploy Migrate for Compute Engine Manager

4 Configure source environment

You then deploy the appropriate appliance based on your source environment: a
backend on vSphere if you are migrating virtual machines from on premises, or an
importer if you are migrating from AWS.
 1 Setup VPN + Network tags

2 Create Google Cloud roles and service

accounts

3 Deploy Migrate for Compute Engine Manager

4 Configure source environment

5 Deploy Cloud Extension

And to complete the process, you deploy a Cloud Extension back at the destination
environment.
 Demo
Installing Migrate for Compute
Engine on AWS

Tad Einstein

In this demo, you will learn how to install the Migrate for Compute Engine’s
infrastructure components on Google Cloud and AWS.

[Presenter]
Once you install all the components, you’ll be ready to start migrating virtual
machines.
 Agenda
Migrate for Compute Engine
Migration Technical Architecture
Installation Process
Migration Process
Lab: Migrating to Compute Engine
Additional Features
Migration Wave
Migrating from VMware

Now that you have learned how to install Migrate for Compute Engine, I will introduce
the migration process from your on-premises or AWS environments to Google Cloud
using Migrate for Compute Engine version 4.x.
 Migration phases

Full Migration Stea

● Run in Cloud: Moves compute to the

cloud; stream storage from
on-premises.
Movi
icon

Chip

After installing Migrate for Compute Engine in your source environment and Google
Cloud, you can start the migration process, which is composed of 3 main phases. I’ll
go over the whole process briefly now, and then go into more details on each step.

The first phase is called ‘Full Migration.’ Migrate for Compute Engine will execute 3
sub steps:
Run-in-Cloud sub-step.
The process starts by turning off the source virtual machine and creating an image. If
you migrate a Windows machine, the process will perform relevant adaptations to the
cloud environment automatically. For linux OS, an rpm package must be installed
manually in advance.

When the image is ready for the cloud, it will be streamed to the Cloud Extension and
boot within a few minutes. Migrate for Compute Engine then streams any data on
demand when the migrated virtual machine needs it.
 Migration phases

Full Migration Stea

● Run in Cloud: Moves compute to the

cloud; stream storage from
on-premises.
Movi
icon

● Storage Migration: Moves storage to

the cloud (in the background).

Chip

The Storage Migration sub-step proactively migrates the full data to the cloud so that
streaming is no longer necessary.
 Migration phases

Full Migration Stea

● Run in Cloud: Moves compute to the

cloud; stream storage from
on-premises.
Movi
icon

● Storage Migration: Moves storage to

the cloud (in the background).

● Prepare to Detach: Prepares to

Chip
disconnect from the on-premises VM.

When storage migration is completed, Migrate for Compute Engine prepares to

detach, which copies all the cached data from the previous operations to a native
Compute Engine persistent disk.

It’s important to note that you can manually go through each of these phases, but we
recommend automatically executing them sequentially by choosing Full Migration.
 Migration phases

Com

1. Detach: Attaches the native disks to

the cloud instance.

2. Clean up: Marks the VM as

unmanaged by Migrate for
Cle
Compute Engine and removes
cloud storage objects

Full migration is just the first out of 3 steps. After full migration is completed, all read
and writes from the migrated virtual machine still goes through the Cloud Extension to
not interrupt the migrated machine’s operation.

When you are ready to fully detach from the cloud extension, which involves brief
downtime, you can initiate the Detach step. It moves the remaining data on the cloud
extension to the native persistent disk and then shuts down the migrated virtual
machine so it can boot natively and securely from its persistent disk, thus becoming
fully independent.
Lastly, a cleanup will mark the VM as unmanaged by Migrate from Compute Engine
and removes migration artifacts.

Let’s go over these steps one by one in more detail.

 Full Migration: Run-in-Cloud sub step

VPC
Migrated VMs

vSphere
iSCSI
On-Premises VMs
Migrate for Compute Engine Cloud Extension
z
Local Compute
Zone: us east1-a Zone: us east1-a
Migrate for Compute
Cloud VPN Edge Node A Edge Node B
Engine Backend

Source VM Snapshot is Boot over WAN, Data is streamed on

Shuts down created in minutes demand to the cloud

VPC
Migrated VMs

When you decide to start a full migration, the first step is called ‘Run-in-Cloud.’
vSphere
iSCSI
On-Premises VMs
Migrate for Compute Engine Cloud Extension
z
During that process,
Local ComputeMigrate for Compute Engine will shut down your source virtual
Zone: us east1-a Zone: us east1-a
machine and create a snapshot of its disk. The platform will then prepare
Migrate for Compute
your virtual
Cloud VPN Edge Node A Edge Node B
machine to run in the cloud and boot the source disk on a Google Compute Engine
Engine Backend

virtual machine. As the migrated destination machine starts in Google Cloud, data
from the source virtual machine will be streamed and cached at the Cloud Extension
Edge Node. All communication traverses through a secure and optimized VPN or
interconnect tunnel.

Startup time for the migrated virtual machine is usually under 10 minutes.
 Data caching and streaming

VPC
Migrated VMs

vSphere
iSCSI
On-Premises VMs
Migrate for Compute Engine Cloud Extension
z
Local Compute
Zone: us east1-a Zone: us east1-a
Migrate for Compute
Data Layer Cloud VPN Edge Node A Edge Node B
Engine Backend

Streaming mode

VPC
During the migration phase, the Migrate for Compute Engine Backend Migrated VMs creates a
vSphere
connection with the Cloud Extension Edge Nodes, which together form a highly
iSCSI

optimizedOn-Premises
and transparent
VMs
data layer. In ‘Run-in-Cloud’
z
mode,
Migrate for Compute data
Engine Cloud Extensionfrom the backend

will be streamed on demand and cached at the Edge

Local Compute
Node.
Zone: us east1-a Zone: us east1-a

Data Migrate for Compute

Engine Backend Cloud VPN Edge Node A Edge Node B
The Layer
Edge Node serves the data to the migrated virtual machine seamlessly. Write
operations are saved in the Edge Node and asynchronously committed back to
on-premises in case you need to roll back.
Streaming mode
The data layer utilizes caching technology that predicts and streams storage as
needed, and the connection benefits from WAN optimizations to ensure optimal
performance.
 Storage Migration

VPC
Migrated VMs

vSphere
iSCSI
On-Premises VMs
Migrate for Compute Engine Cloud Extension
z
Local Compute
Zone: us east1-a Zone: us east1-a
Migrate for Compute
Data Layer Cloud VPN Edge Node A Edge Node B
Engine Backend

Full Storage Migration

VPC
Migrated VMs

After the vSphere

streaming mode is stable and the destination machine is fully operational, it’s
iSCSI
time for the data migration step.
On-Premises VMs
Migrate for Compute Engine Cloud Extension
z
Local Compute
Zone: us east1-a Zone: us east1-a
WhenData
an on-premises
Migrate for ComputeVM is running in Google Cloud, storage is streamed in order to
Edge Node A Edge Node B
Engine Backend Cloud VPN
reduce downtime, and storage blocks are only transferred and cached on Google
Layer

Cloud when needed.

The next step is called ‘storage migration,’

Full Storage Migration which transfers the data in full to the Edge
Nodes while the migrated virtual machine is still running in the background. The
process is completely transparent to the migrated virtual machine, which remains fully
operational from the moment it started.
 AWS Migration

VPC
Migrated VMs

iSCSI
AWS EC2 VMs
Migrate for Compute Engine Cloud Extension
EC2 Virtual Machine
Zone: us east1-a Zone: us east1-a
Migrate for Compute
Cloud VPN Edge Node A Edge Node B
Engine Importer

VPC
Migrated VMs

If you are migrating from AWS, the process is quite similar except for a few details.
iSCSI
AWS EC2 VMs
Migrate for Compute Engine Cloud Extension
z
When you initiate
EC2 Virtualthe
Machine‘Run-in-Cloud’ phase, Migrate for Compute Engine creates a
Zone: us east1-a
new virtual machine, called an Importer, in your AWS environment,Zone: us east1-a
which facilitates
Migrate for Compute Edge Node A Edge Node B
Cloud VPN
the data streaming process within the destination environment in Google Cloud. Once
Engine Importer

your data is migrated in full to Google Cloud, you will delete the Migrate for Compute
Engine Importer virtual machine on AWS because it is no longer needed to stream or
transfer your data.
 Prepare to Detach
VPC

VPC

Migrated VMs
Mi

iSCSI
z
Migrate for Compute Engine Cloud Extension

Zone: us east1-a Zone: us east1-a

Edge Node A Edge Node B

Persistent Disk

When the data is fully migrated to the Edge Nodes, the next step is to prepare to
detach the migrated virtual machine. Until now, the migrated virtual machine’s data
was served from the Edge Nodes which handled the streaming and migration, which
is an efficient intermittent state that minimizes downtime and mitigates risk. Now that
all the data is cached in the Edge Node, a prepare to detach phase will save the data
to a native Compute Engine persistent disk so that the migrated virtual machine can
function independently.

Read and write operations are still being saved and cached at the Edge Nodes in
order to keep the migrated virtual machine running smoothly, and you can still roll
back the migration to on-premises if you need to.
 Detach VPC

Migrat
VPC z

Migrated VMs Zon

iSCSI

Migrate for Compute Engine Cloud Extension

Zone: us east1-a Zone: us east1-a

Edge Node A Edge Node B

The detach phase is initiated manually and incurs a brief downtime while the virtual
machine is shut down and last writes are being synced to the persistent disk. Then,
the persistent disk detach from the cloud extension and attach to the virtual machine,
and a native boot from it is initiated. At this point, the virtual machine runs
independently and data is read and written from the native persistent storage.
 Cleanup C

VPC
VP
Migrated VMs

Migrate for Compute Engine Cloud Extension z

Zone: us east1-a Zone: us east1-a

Edge Node A Edge Node B

The last manual step is Cleanup, which Marks the VM as unmanaged by Migrate for
Compute Engine and removes migration artifacts from the Edge Nodes.
 Demo
Migrating from AWS to
Google Cloud

Tad Einstein

In this demo, you will learn how to migrate a virtual machine from AWS to Google
Cloud
 Lab Intro
Migrating to Compute Engine

Now that you have learned how to migrate virtual machines from your source
environment to Google Cloud, let's apply the migration process in a lab.

In this lab, you use Migrate for Compute Engine to migrate a VM instance (EC2) that
exists on AWS to Google Cloud. This will be a "lift and shift" operation. When
completed, the VM instance that was running on AWS will be running on Google
Cloud.
 Lab Solution
Migrating to Compute Engine

Chris Lupone

In this lab you utilized a Terraform script to deploy an AWS instance. You then
configured Compute Engine Manager (formerly Velostrata) to migrate your AWS
instance to a Google Cloud VM.

You can stay for a lab walkthrough, but remember that Google Cloud's user interface
can change, so your environment might look slightly different.
 Agenda
Migrate for Compute Engine
Migration Technical Architecture
Installation Process
Migration Process
Lab: Migrating to Compute Engine
Additional Features
Migration Wave
Migrating from VMware

In this video, you will learn about other features Migrate for Compute Engine
supports, like test clones and offline migration.
 Test clone (Optional)

VM On- Compute
Premises Engine Clone VM

Streaming
VM Snapshot Data Layer

S
● Thin clones start in cloud in 5 minutes!
● Data is streamed and cached
● On-premises virtual machine keeps running

Testing your applications in the cloud before you officially migrate them is an
important way to save time and mitigate mitigation risk. It gives enterprises the
opportunity to easily see how applications perform in the cloud and to make the
appropriate adjustments before going live.

Creating a test clone is completely optional, but we recommend testing virtual

machines before putting them in production. Unlike the migration process, test clones
leave the on-premises VM running and create an identical clone of that machine from
a snapshot of the source virtual machine. That image begins to transfer to the source
environment, Google Cloud.

Thanks to its streaming technology, Migrate for Compute Engine starts a thin clone in
the cloud within about 5 minutes. The machine’s data is streamed over a secure
connection to a highly optimized cache.
There are a few points to be aware of. First, each VM can have a maximum of one
test clone at a time.

Second, Windows virtual machines are automatically configured to run in the cloud,
but linux-based virtual machines needs to have an rpm package manually installed.
 Test clone isolation (Optional)

On

On-Premises Google Cloud

VM On-Premises
Isolated VPC

VM On
Compute Engine
Clone

Database

Databa

In addition, the test clone virtual machine is created in write-isolation storage mode.
That means that changes in the cloud-based clone storage are not written back to
on-premises storage. It’s important to remember that test clones are exact copies of
your source workload, including any credentials, data, and state it is using. And both
of them are running at the same time!

We recommend that you use test clones in an isolated VPC or subnet to avoid
conflicts or race conditions with other services such as Active Directory, DNS, and
shared repositories.
 Test Clone Isolation (Optional)

On-Premises Google Cloud

VM On-Premises
Isolated VPC

Compute Engine
Clone VM On
Database

After testing your workload with a test clone, you should delete it. Deleting the test
clone removes it from Google Cloud.

Note that deleting the test clone has no impact whatsoever on your live system or
data. No changes made to data in the test clone are written back to your live system.
 Offline migration

Source VM is shut down

● Enables you to migrate workloads with

(typically) legacy operating systems that are Storage migrates completely to
not currently supported by Migrate for Cloud Extension
Compute Engine.

● Can also be used for “storage-only migration.” Storage is being detached from Cloud
Extension to Persistent Disk

Migrated VM starts at Google Cloud

With offline migration, Migrate for Compute Engine enables you to migrate workloads
running on vSphere with operating systems that are not currently supported by
Migrate for Compute Engine's streaming technology. These are typically legacy
operating systems.

During the offline migration process, all storage migrates to the cloud before the VM
starts on Compute Engine. The source virtual machine will first shut down, and
storage will be migrated completely, detached, and cleaned up before the VM starts in
Google Cloud. Since data cannot be streamed, the downtime is measurably longer
and depends on the connection and amount of data that needs to be transferred.
 Offline migration

Supported VM

Legacy disk
Supported VM
image

Offline migration can also be used for “storage-only migration.” Legacy VMs can be
migrated to the cloud with offline migration, even when unsupported in Compute
Engine. Administrators can then reattach a data disk to a newer and supported cloud
instance to retrieve data from it.
 Agenda
Migrate for Compute Engine
Migration Technical Architecture
Installation Process
Migration Process
Lab: Migrating to Compute Engine
Additional Features
Migration Wave
Migrating from VMware

In this video, you will learn how to migrate more than one virtual machine at a time,
using a feature called a Migration Wave.
 Migration waves

Supported VM

So far in this module you’ve learned how to migrate a single virtual machine.
Enterprise cloud migration projects often include moving hundreds or thousands of
application workloads from on-premises or other clouds into Google Cloud. Migrating
the entirety of your data center at once is challenging, if not impossible. It’s important
to assess your workloads and batch them into different migration groups.

One of the main decision drivers of a migration group is often related to application
affinity, where certain systems must maintain specific latencies between each other. In
those types of scenarios, you will want to migrate these applications as one migration
group, called a migration wave. A migration wave is a way of organizing the systems
you want to move into batches that make your migration strategy more manageable.
 Choosing the first migration wave

1 Business Criticality

Now that you understand why we leverage Migration Waves, let’s discuss how we go
about choosing which systems to group together for your first Migration Wave.

One of the most important considerations to think about when choosing systems for
the first wave is to focus on the business criticality of the individual workload. We
recommend choosing workloads and underlying systems that are the least
business-critical. These workloads will give you the opportunity to get comfortable
with your migration process while minimizing risk early on in the migration.
 Choosing the first migration wave

1 Business Criticality

2 Lifecycle Environment

Another recommendation would be to migrate your application development or test

environment first.
 Choosing the first migration wave

1 Business Criticality

2 Lifecycle Environment

3 Uptime Sensitivity

You will also want to consider your applications’ Service Level Agreements and
uptime requirements. Workloads that can experience interruption and downtime
without major business impact or batch processes are also excellent migration
workloads for the First Wave.
 Choosing the first migration wave

1 Business Criticality

2 Lifecycle Environment

3 Uptime Sensitivity

4 Licensing and Compliance

Another point that is important to consider is your workloads’ licensing and

compliance requirements. A good first mover is either a workload that is developed
in-house or one whose licensing requirements support running in a cloud
environment. Low compliance complexities are another indicator of a strong First
Wave candidate.
 Choosing the first migration wave

1 Business Criticality

2 Lifecycle Environment

3 Uptime Sensitivity

4 Licensing and Compliance

5 Dependencies

Lastly, when choosing your First Wave candidates, you want to select workloads that
have fewer system and
network-to-network dependencies. By taking this approach, you minimize your
migration scope and reduce technical complexities.
 Migration wave components
Wave Jobs

On each Wave you

initiate migration jobs
(Full Migration, Detach,
Cleanup). These
migration jobs are being
ran on all the VMS
specified in the runbook
assigned to the Wave

Supported VM

Wave
A construct for batch migration of VMs

A wave is a high-level construct that represents a migration batch. When you migrate
a large number of machines, you will do it in batches, which makes sense in terms of
interdependency and other technical requirements.
 Migration wave components
Wave Jobs

On each Wave you

initiate migration jobs
(Full Migration, Detach,
Cleanup). These
migration jobs are being
ran on all the VMS
specified in the runbook
assigned to the Wave

Runbook Wave Supported VM

The spec file describing the source VM A construct for batch migration of VMs
in the wave along with Target
specification per each VM.

When creating a wave, you are

providing a runbook spec file.

You can replace the runbook assigned

to the wave at any time.

A runbook is a CSV file that specifies the VMs to be included in a wave and the
configuration of target VMs. It describes the source VM, defines properties for the
target VM and networks, and also contains other metadata.
 Migration wave components
Wave Jobs

On each Wave you

initiate migration jobs
(Full Migration, Detach,
Cleanup). These
migration jobs are being
ran on all the VMS
specified in the runbook
assigned to the Wave

Supported VM
Wave jobs Runbook Wave
On each wave you initiate migration The spec file describing the source VM A construct for batch migration of VMs
jobs (Full Migration, Detach, Cleanup). in the wave along with Target
These migration jobs are being run on specification per each VM.
all the VMS specified in the runbook
assigned to the wave. When creating a wave, you are
providing a runbook spec file.

You can replace the runbook assigned

to the wave at any time.

A job is the migration operation that Migrate for Compute Engine performs on the list
of VMs in the runbook. Migration operations include creating test clones, full
migration, and detaching, the same operations you’ve learned about previously in this
module.
 Demo
Migration Waves

Tad Einstein

In this demo, you will learn how to migrate multiple virtual machines from VMware's
vsphere to Google Cloud leveraging migration waves.
 Agenda
Migrate for Compute Engine
Migration Technical Architecture
Installation Process
Migration Process
Lab: Migrating to Compute Engine
Additional Features
Migration Wave
Migrating from VMware

In this lesson, you learn how to migrate from VMware, using Migrate for Compute
Engine 5.x. The migration process is a bit different than what you learned earlier for
AWS and Azure.
 Migrate for Compute Engine (MFCE) 5
● The latest version of MFCE 5 offers a simpler,
more powerful way of migrating VMware VMs.
● MFCE 5 is a managed service.
○ There is no longer deploy a Google
Marketplace app to deploy.
○ Instead, enable the Compute for Migrate
Engine API.
● There are not as many details to manage directly.
● Configuration is done within Cloud Console.
● Migration of multiple VMs initiated and managed
within Cloud Console.

Migrate for Compute Engine (MFCE) 5 makes migrations of VMware VMs simpler to
install, configure, and manage.

MFCE is implemented as managed service. There is no Google Marketplace app to

deploy. The feature is directly integrated with Cloud Console.

In MFCE 5, there are not as many details to manage directly - and those details are
mostly managed within Cloud Console. VM migration is initiated in Cloud Console -
not on the migration source. The migration source sends environment information to
Google Cloud - including VMs available to migrate.

Using MFCE 5, you can use Cloud Console to migrate multiple VMs. All aspects of
this migration are managed within Cloud Console.
 Migrate for Compute Engine (MFCE) 5
● Migration is done using replication, not streaming.
○ No more Cloud Extensions/edge nodes.
○ No agent is needed on the migrated VMs
(agentless migration).
● Minimal connectivity requirements from the
migration source.
○ Migrations can be performed over HTTPS,
using port 443, to access Google Cloud APIs.
○ Cloud VPN or Cloud Interconnect are no
longer required (but still supported).

Migration is done using replication, not streaming. There are no more Cloud
Extensions to install. Processing previously done by the edge nodes - configured by
the Cloud Extensions - is now done using preconfigured components within Google
Cloud. The migration is agentless.

Migrations no longer require Cloud VPN or Cloud Interconnect. Migration can now be
run on the public internet. It is done over HTTPS, using port 443, to access Google
Cloud APIs.
 Caveats
● MFCE 5 is available only for VMware VMs.
○ For VMs on other platforms, continue to use MFCE 4.x.
○ MFCE 4.x can exist in parallel with MFCE 5.
● MFCE 5 is available from selected regions.
○ The VPC network used for migration must be in a region supported by MFCE 5.
○ Additional supported regions are continually being added.

Currently, MFCE 5 is available only for VMware VMs. To migrate VMs from other
platforms - such as on AWS or Azure - use MFCE 4.x. MFCE 4.x can be used in
parallel with MFCE 5.

MFCE 5 is available only from selected regions. The VPC network used for migration
must be in a supported region. The list of available regions will expand over time. For
a list of currently available regions, refer to the link in the Course Resources.

https://cloud.google.com/migrate/compute-engine/docs/5.0/resources/locations.
 Architecture
● Migrate Connector: Facilitates ● Host project:
agentless VM data replication to ○ Migrate service API is enabled.
Google Cloud. ○ Use Cloud Console to interact with project components.
● Target projects: Contain landing zones for migrated VMs.

Migrate for Compute Engine Host project

vSphere on-premises
Migrate for Cloud
HTTPs to Compute Engine IAM
On-premises vCenter Cloud API Cloud
VMs Server (port 443) APIs Compute Google Cloud
Engine Console

Migrate
Target project Target project
Connector

The Migrate Connector in MFCE 5 replaces the Migrate for Compute Engine
On-Premises Backend from MFCE 4.x. Like the Migrate for Compute Engine
On-Premises Backend in MFCE 4.x, the Migrate Connector is installed in VMware
VSphere using an OVA file. The Migrate Connector sends information from the
VMware environment to Google Cloud. The information is then available for use in
Cloud Console for migrations. In the lab, you learn how to configure VSphere to work
with MFCE, install the OVF file, and register the Migrate Connector. Except for
installing the Migrate Connector in VMware vSphere, all other migration tasks are
done from Google Cloud.

In the Migrate for Compute Engine host project, you enable the Migrate for
Compute Engine API. Migrations are configured and managed from the host project,
using Google Cloud Console.

You configure migrations to put virtual machines in a target project. The target project
is the landing zone for new VMs. You can have multiple target projects or even no
target project. If you do not specify a target project, the host project becomes the
landing zone. In other words, after migration, you will find the new virtual machines in
the host project.
 Migration: From start to finish
Start replication
● No disruption to the on-premises VM.
● Initial first sync is followed by periodic replication.

On-premises data
center Host
project

First sync

When you replicate a VM to Google Cloud, there is no disruption to the on-premises

VM. It continues to run while the replication occurs. Migrate for Compute Engine
creates the initial VMware snapshot of the source VM data disks and replicates the
snapshot data to Google Cloud. Depending on the amount of disk data on the source
VM, the first replication can take minutes or hours to complete.

The first replication does not automatically result in the creation of a cloned VM in
Google Cloud. It replicates data that can be used to build a test clone. Building a test
clone is an optional, separate step. You’ll learn more about building a test clone in a
moment.

After the initial VM replication is complete, there are subsequent periodic replications.
These periodic replications keep the VM data in the Cloud in sync with the VM data in
the on-premises environment. Periodic replications are incremental. The frequency of
the periodic replications can be configured in Google Cloud.

At any point after the initial replication, you can build a test clone of the migrated VM.
 Migration: From start to finish
(Optional) Create test clone
● Validate source VM clone in the Google Cloud before cutting over (optional).
● The VM OS is seamlessly adapted to Google Cloud.

Target projects
On-premises data
center Host Test
project project

Periodic replication

To ensure that VM was migrated correctly, you can build a test clone in Google Cloud.
Building a test clone can be done fairly quickly. After the cloned VM has been started,
you can run any desired tests to make sure the VM was created correctly and
performs as expected.

Building a test clone is optional. However, it is a best practice to perform testing

before deploying a migrated VM to production. The test-clone Compute Engine
instance is created from the most recently completed replication step.
 Migration: From start to finish
Cut over to the cloud
● Cut over to Google Cloud in the scheduled maintenance window.
● Source VM is powered off.
● Final sync of VM data to Google Cloud is completed.
● Migrated VM OS is adapted to Google Cloud.

Target projects
On-premises data
center Host Test Production
project project project

Final sync

When the migration is complete and you are satisfied that it worked, you can cut over
to Google Cloud. Cutting over to Google Cloud powers off the source VM in VMware.
A final data synchronization from the source VM to the migrated VM in Google Cloud
is completed, and the migrated VM operating system is adapted to Google Cloud.
 Single Pane of Glass
Use Google Cloud Console to:
● Perform migrations of single VMs or
groups of VMs.
● Create test clones.
● Cut over to Google Cloud.
● View statistics for:
○ Migrations in progress
○ Past migrations

Cloud Console enables you to manage and view migration information from a central
location. You can perform migration of single VMs or groups of VMs, create test
clones, delete the source VM in VMware, and cut over to the VM running in Google
Cloud. You can also view statistics for past migrations and migrations in progress.

In other words, in MFCE 5, you use Cloud Console for virtually all of your migration
tasks.
 The Migrate Connector
● Use VMware to install and configure
the Migrate Connector.
● Each Migrate Connector installed
becomes a migration source.
● In Cloud Console, you can select
which Migration source to use.

Although you use Cloud Console for virtually all of your migration tasks, you still install
and configure the Migrate Connector in one or more VMware deployments.

Each installed Migrate Connector becomes a migration source.

After successfully installing a Migrate Connector, you can see its associated migration
source - and all of the VMs in that VMware deployment - in Cloud Console.

In Cloud Console, you select which migration source to use. By switching migration
source, you switch which VMware deployment to use for migrations. Thus, with
multiple migration sources, you can migrate VMs from multiple VMware deployments
into Google Cloud.
 Migrating groups of VMs
● Create a group containing one or more VMs.
● Groups provide flexibility in working with multiple VMs.
● Actions can be performed on an entire group or on selected VMs within the group.
● Migrate, test clone, and cut over multiple VMs at once.

Using Google Cloud Console, you can create a group and associate it with one or
more VMs. Groups provide flexibility and ease in working with multiple VMs. Instead
of performing an action on a single VM, you can perform an action on the VMs in a
group. For example, in Cloud Console, you can navigate to a group, select its VMs,
and then perform a migration, test clone, or a cutover. The action executes on all the
selected VMs within the group. To perform an action on a subset of VMs within a
group, select the VMs that comprise the subset and then select the desired action.
Also note that you can move VMs from one group to another. Using groups makes it
easier to deal with large numbers of VMs.
 Demo
Installing Migrate for Compute
Engine on vSphere

Chris Lupone

In this demo, you will learn how to install the Migrate for Compute Engine’s
infrastructure components on Google Cloud and vSphere.

[Presenter]
Once you install all the components, you’ll be ready to start migrating virtual
machines.
 Demo
Migrating from vSphere to
Google Cloud

Chris Lupone

In this demo, you will learn how to migrate a virtual machine from on-premises to
Google Cloud
 Migrate for Compute
Engine - Review

In this module, you learned about Migrate for Compute Engine architecture, including
how to install it in your source environment, the migration process, and special
features like running a test clone. You then learned how to use migration waves to
organize the systems you want to move into batches. This makes your migration
strategy more manageable and allows you to migrate a large number of machines at
once.

In the next module, we will show you how to to create a Cloud Identity account to
manage the user account lifecycle, and sync users from your on-premises
environment to the cloud. In addition, we’ll share some best practices on how to
structure your resource hierarchy as your cloud footprint grows in size. We will also
discuss how to centrally manage a single network across multiple projects, known as
Shared VPC. Lastly, we’ll show you how to manage an identity provider across
environments.

Move on to the next module to learn more.