The Migrate Phase

Assess/Discover Plan/Foundation Migrate! Optimize your

your application Create a landing Pick a path, operations and
landscape zone to the cloud and get started save on costs

Cloud migration is the journey, the end-to-end lifecycle whereby

things move from other locations (on-prem, other clouds) and into
GCP is the destination where these things migrate to,
the GCP.
and which are often modernized/optimized in-cloud
afterwards.
 Learn how to...
Install and configure Migrate for Compute Engine

Migrate VMs from vSphere and AWS using Migrate for

Compute Engine

Automate migration for waves of VMs

Move VMs back to their source environment

Deal with special case situations

Migration with Migrate for Compute Engine includes:

1. Testing with clones
2. Running in cloud
3. Migrating
4. Detaching and Cleaning up
Automation includes:
1. Creating runbooks with configuration settings for batches of machines
2. Migrating waves of machines at once
Moving machines back:
1. Could happen during outage
2. Could happen because things don't work as desired
Special case situations:
1. Custom adaptations
2. BYOL licensing
3. Bare metal
4. Offline migrations
5. Etc.
Agenda
Introduction

Migrate for Compute Engine concepts and requirements

Migrate for Compute Engine installation

Basic migration operations with Migrate for Compute Engine

Automating migrations with Migrate for Compute Engine

Application and special case migrations

Summary and next steps

 The Migrate phase is where VMs actually move

Having established a plan for the first migration waves, here’s where you get started.

Input Activites Output

● GCP migration landing zone
● Migration backlog
● Business prioritisation
● Install and configure Migrate for
Compute Engine
● Create waves and runbooks
● Define configurations for special apps
● Migrate waves of applications
● Successfully migrated workloads
● Lessons learned
● Updated operating model

At this point, you have will proceeded through the Discover/Assess and
Plan/Foundation phases. You should know what you're going to move, and have a
prepared environment to move into.

The goal for this phase is to get Migrate for Compute Engine up and running,
configure your automation, and do the migrations.

Coming out of this phase, you should have both migrated workloads, and
improvements to the migration sprint process.
 Migrations happen in sprints and waves
Migrate
Prepare Execute move of
Build target
apps and
environments and
services to GCP
select migration
candidates from
backlog

Migration
Improve
Learn lessons,
Sprint
improve Test / Verify
Conduct UAT and
migration
regression testing
process

Optimize
Decouple state
and stateless,
scale horizontally,
rightsize & PVM

1. Sprint = time-bound work period, with specific apps to migrate pulled from
backlog
2. Do any sprint-specific discovery tasks that need revision/completion
3. Do any remaining sprint-specific planning tasks that need revision/complete
4. Execute the migration
5. Test your migration and make sure everything works
6. Consolidate your learning and refine your process for future waves
7. For some workloads, you will move onto the Optimize phase (which we'll be
doing later in this class)
 In this course, Migrate is focused on lift and shift

● Automated approach for large numbers of VMs

● Typically limited change
● Focus on…
○ Velocity
○ Reliability and repeatability
○ Minimal toil (maximum automation)
○ Ability to revert or fall back if needed

● Good tools are critical

What we're talking about is large scale lift and shift migrations. We're not focused on
manually-intensive single VM migrations, or on refactoring of applications.
Agenda
Introduction

Migrate for Compute Engine concepts and requirements

Migrate for Compute Engine installation

Basic migration operations with Migrate for Compute Engine

Automating migrations with Migrate for Compute Engine

Application and special case migrations

Summary and next steps

 Migrate for Compute Engine is a key migration tool

● Field-proven
● VMware, AWS, and Azure
sources
● Moves compute immediately
(<10 minutes)
● Data is "streamed" to cloud until
app is live in cloud
● Testing and fallback/reversion
available

Migrate for Compute Engine was acquired by Google. It's been used to migrates tens
of thousands of VMs to date. It supports migrating workloads from VMware
installations using vCenter, as well as AWS/Azure accounts. Should note that this is
an agentless technology.

At a high level, what Migrate for Compute Engine does is…

1. Creates a new VM in GCP to handle the processing for the workload and
shuts down the original
2. Creates a data streaming conduit from the disks in the source environment.
a. VM disk data is sent over the network to a caching location in GCP,
where the GCP VM accesses it.
b. VM disk data that's changed on the GCP VM can be synched back
with original disk
c. For full migration, you can have Migrate for Compute Engine cache all
data into GCP and then detach from the source (creating a GCP disk
that has all the VM data and is attached to the VM)

Because of the streaming data strategy, VMs can moved to the cloud with 10 minutes
downtime as opposed to hours that might be required to replicate all the VM disk data
over. Note that there is another chunk of downtime as the "detach" process is
completed.
Migrate for Compute Engine allows you to clone a VM for testing purposes. This will
create a new VM in the cloud while leaving the original VM active. The VM in the
cloud gets streamed data from the source, and doesn't sync changes made on the
clone back to the source. This allows you to test a copy of your workload in the cloud
prior to migration. You can then delete the clone when testing is done.

Migrate for Compute Engine allows you to take a VM running in the cloud and move it
back on prem. This reverses the streaming, deletes the cloud VM, and rebuilds the
original VM.

Azure support coming this summer.

 Migrate for
Compute
Engine
architecture

Things to note when reviewing this diagram:

1. The source and target networks are connected, in this case using VPN tunnels
2. The Migrate for Compute Engine Manager is a GCE VM deployed into a GCP
project. This VM will orchestrates the migration operations and provides a
Web UI.
3. The Migrate for Compute Engine backend is a virtual appliance deployed into
your vSphere environment. It handles the datacenter part of streaming data.
a. It communicates with GCP API endpoints and Stackdriver
4. The Migrate for Compute Engine vCenter Plugin provides management
functionality within the vCenter UI.
5. The Cloud Extension handles the data streaming on the GCP side.
a. It's comprised of a couple of edge node VMs (2 VMs in 2 zones for HA)
b. The serve as a bridge between the migrated VMs and the storage
caching tier (using iscsi)
c. Edge nodes communicate with GCS and Stackdriver
6. In AWS, the Migrate for Compute Engine importer handles the AWS side of
data streaming

Note that the Migrate for Compute Engine Exporter is not shown here. When you
detach a VM, and exporter instance is deployed and continues to handle the GCP
side of data sync until the detach is complete.

Some other notes...

● Secure by design: Data transfers between Migrate for Compute Engine
components use SSL and AES-128 encryption. Data at rest is
de-duplicated, compressed, and encrypted with AES-256.
● Boot over WAN: Migrate for Compute Engine performs a native boot in
the cloud from the your VMs in a few minutes, regardless of image size.
While the image boots, Migrate for Compute Engine adapts it for the
target environment. No changes to the application, original image,
storage, drivers, or networking are necessary.
● Intelligent streaming: Migrate for Compute Engine prioritizes the data
necessary for an application to run and moves that data to the cloud
first. Other data is streamed to the cloud when needed.
● Multi-tier caching and optimization: Migrate for Compute Engine
includes a multi-tier, read-write cache in the cloud. This cache stores
data needed by the application. De-duplication, pre-fetching,
asynchronous write-back, and network optimizations further accelerate
the migration, reducing migration bandwidth by up to 75% in production
migrations.
● Resiliency: Migrate for Compute Engine Cloud Extensions use an
active-passive configuration across two availability zones. Data is
written in both zones and then asynchronously transferred back on
premises to reduce the risk of data loss. Optionally, writes can persist
solely in the cloud for development and testing.
● The recovery point objective (RPO) is the maximum acceptable length
of time during which data might be lost due to an incident. Migrate for
Compute Engine's architecture ensures a 30-second RPO for sync to
Google Cloud Storage in the rare case of a dual zone failure and a
1-hour RPO for sync on-premises.
 Migrate for Compute Engine pre-reqs: network

● Connectivity via…
○ Dedicated Interconnect
○ Partner Interconnect
○ VPN

● Bandwidth recommended...
○ 50 Mbit/sec base
○ 1Mbit/sec for each VM
concurrently migrated

● Firewall rules and routes enable

traffic flow
○ Between source and target
○ Within source and target

https://cloud.google.com/migrate/compute-engine/docs/4.8/concepts/requirements
https://cloud.google.com/migrate/compute-engine/docs/4.8/concepts/planning-a-migra
tion/network-access-requirements

Docs say minimum bandwidth required is 20/0.5. Realistically, you should go with
recommendations.

For connectivity, you will want a robust interconnect between source and target
networks. If using VPNs, you might consider HA VPN.

You can limit the amount of bandwidth used by Migrate for Compute Engine by using
bandwidth throttling. Obviously, the lower the limit of bandwidth used, the smaller the
batches of VMs you can migrate.

The firewall rules noted in the diagram are recommendations focused on successful
Migrate for Compute Engine use. Notice…
1. The Migrate for Compute Engine manager talks to the cloud edge nodes and
the migrated VMs
2. The Migrate for Compute Engine backend talks to the Migrate for Compute
Engine Manager and the Cloud Extension
3. vCenter talks to the Migrate for Compute Engine Manager
4. The edge nodes talk to each other and the Migrate for Compute Engine
Manager
 1. The migrated VMs talk to the edge nodes
2. You need to ensure additional firewall rules to allow for correct operation of
workloads

Note: Your on-prem and AWS networks must be configured to allow appropriate traffic
flow as well. For instance, the Migrate for Compute Engine Backend must be able to
talk to the vCenter and ESXi hosts, as well as Stackdriver and GCP-based Migrate for
Compute Engine components.
 Migrate for Compute Engine pre-reqs: OS versions

Windows Windows Server 2008 R2 SP1+

Windows Server 2012 and 2012 R2
Windows Server 2016 and 2019
Windows Server 2003, 2003 R2, 2008 R1 (offline)

Linux AWS Linux AMI, Linux 2

CentOS 6.4+ and 7
RHEL 6.4+ and 7
Debian 8.5+ and 9
Ubuntu 14/16/18; 12 (offline)
SUSE 11 SP3+, 12 SP2/3/4, and 15

https://cloud.google.com/migrate/compute-engine/docs/4.8/concepts/requirements
https://cloud.google.com/migrate/compute-engine/docs/4.8/reference/supported-os-ve
rsions

Offline migration entails greater downtime. Also remember that Linux VMs require
preparation in the form of installing the Migrate for Compute Engine RPM.
https://cloud.google.com/migrate/compute-engine/docs/4.8/resources/downloads

Support almost all GCE-supported OSes.

 Migrate for Compute Engine pre-reqs: VMware as a
source
ESXi 5.5U1, 6.0 U1, 6.5, 6.7

vCenter 5.5U1, 6.0U1, 6.5, 6.5U1, 6.7

Permissions For setup: Ability to deploy OVA, create roles/users

For operation: see documentation

https://cloud.google.com/migrate/compute-engine/docs/4.8/concepts/requirements
https://cloud.google.com/migrate/compute-engine/docs/4.8/how-to/configure-manager
/configuring-vms-vm

Note that vCenter is mandatory. Version 5.0/1 may be used in certain configurations.

For installation, you can use an administrator or delegated admin account.

For operation, the best way is to create a role with required privileges using the
provided script.

● Alarms
○ Create alarm
○ Modify alarm
○ Remove alarm
○ Set alarm status
● Datastore
○ Low level file operations
● Extension
○ Register extension
○ Unregister extension
 ○ Update extension
● Global
○ Cancel task
○ Enable methods
○ Disable methods
○ Licenses
○ Log event
● Task
○ Create task
○ Update task
● Virtual Machine
○ Provisioning > Allow disk access
○ Provisioning > Allow disk read-only access
○ Provisioning > Allow virtual machine download
○ Snapshot management > Create snapshot
○ Snapshot management > Remove snapshot
○ Snapshot management > Revert to Snapshot
○ Snapshot management > Rename Snapshot
○ Configuration > Configure managedBy
○ Interaction > Power On
○ Interaction > Power Off
 Migrate for Compute Engine pre-reqs: AWS source

● AWS account
● AWS IAM user account to manage resources
○ Programmatic Access
○ Downloaded keys provided to Migrate for Compute Engine

● The best way to assign required permissions…

○ Create and assign an IAM group
○ Migrate for Compute Engine provides a Cloud Formation template

https://cloud.google.com/migrate/compute-engine/docs/4.8/how-to/migrate-aws-to-gc
p/aws-prerequisites
https://storage.googleapis.com/Migrate for Compute
Engine-release/V4.2.0/Latest/CloudFormation.zip
Agenda
Introduction

Migrate for Compute Engine concepts and requirements

Migrate for Compute Engine installation

Basic migration operations with Migrate for Compute Engine

Automating migrations with Migrate for Compute Engine

Application and special case migrations

Summary and next steps

 Resource management: single project
Organization VM Role assignment
Cloud Migration Infra Manager Role Velostrata Manager SA CE Role assignment
Cloud Migration Storage Access Role Velostrata Cloud Extension SA
Migration Project

VPC

Project
Migrate for Compute VM subnet (us-east 1)
Engine subnet (us-east1)

Velos Manager Migrated VM

Compute Engine Compute Engine VM subnet (us-west1) Project

Velos Edge Migrated VM

Compute Engine Compute Engine VPC <-> Source
Cloud VPN
Project

Using a single project for the Migrate for Compute Engine infrastructure and migrated
workloads is the simplest scheme.

In this setup
● You create roles at the project level that combine the necessary permissions
for the Manager and Extension services.
● You also create service accounts, one for the Manager and one for
extensions.
● You then assign the roles to the service accounts
● You can place all the Migrate for Compute Engine components in their own
subnet (or not)
● All migrated resources end up within the source project
This structure might make sense for POCs, but 99% of the time it's too simple.
 Resource management: Shared VPC
Infra Role assignment
CE Role assignment (optional)
Cloud Migration Infra Manager Role
Organization Cloud Migration Storage Access Role
Velostrata Manager SA
Velostrata Cloud Extension SA
VM Role assignment
Migrate for Compute Engine Project (Shared VPC Host) CE Role assignment
Service project
VPC

Migrate for Compute Engine VM subnet

Migrated VMs
subnet (us-east1) (us-east1)
Compute Engine

Velos Manager
Compute Engine

Velos Edge Service project

Compute Engine
VM subnet
(us-west1) Migrated VMs
Compute Engine

Often, companies will want to place different workloads in different project. In these
cases, you can use Shared VPC networks and multiple projects.

In this setup
● You create roles at the project level that combine the necessary permissions
for the Manager and Extension services, but at the ORG level so they can be
used by all projects.
● You also create service accounts, one for the Manager and one for
extensions, within the Host project (which houses your Migrate for Compute
Engine resources)
● You can either assign roles to the service accounts on individual service
projects, or assign at the org of folder level and have the assignment inherit
down
● Migrated VMs go into service projects, but are connected to the host VPC
assets
 Configuring required service accounts and roles
Velostrata Manager Cloud Migration Infra
service account Manager role

Velostrata Cloud
Cloud Migration Cloud
Extension service
Assignments Extension role
account
Cloud IAM

GCP Project

python3 /google/velostrata/velostrata_sa_roles.py -p
infrastructure-project -d deployment-name

● Migrate for Compute Engine provides a script to create roles, service

accounts, and role bindings in your project or organization
● Run from Cloud Shell
● The optional -o switch allows you to define custom roles at the org level
● To run the script, you must have an account with appropriate permissions at
project (and optionally organization) level.
○ Role administrator
○ Service account admin
○ Project IAM admin
○ etc.
● Script will automatically start required services within the migration project
● If org switch is set, roles are defined at org level and policy bindings are
configured at org level
● Migrate for Compute Engine Manager, running in its service account, creates
objects in projects (e.g. Cloud Extension VMs, GCS buckets, etc.)
● Migrate for Compute Engine Cloud Extension and exporter VMs, running in
their service account, reads and writes objects to GCS
 Installing Migrate for Compute Engine Manager
Velostrata Manager Net Tag:
Service Account fw-velosmanager

Velos Mgr.
Compute Engine

Edge Nodes
Compute Engine

Migrated VMs
Compute Engine

GCP
Cloud APIs

The Migrate for Compute Engine Manager orchestrates migration operations and
serves the Web UI.

It's installed via the GCP Marketplace

1. Search for Migrate for Compute Engine
2. Configure deployment options
3. Click to deploy
Deployment creates a VM that runs with Migrate for Compute Engine Manager
service account (with the Migrate for Compute Engine
Manager role). Assigned network tags control network connectivity

The Manager VM needs to access GCP API endpoints. The management UI should
not be accessible from the public internet; you'll need to access it using a machine
that can route traffic to the internal IP address.

You might install multiple Manager appliances if you are migrating to different projects
and shared vpcs, or if there are multiple teams doing migrations, etc.
 Migrate for Compute Engine backend

● Connects to VM disks in your on-premises data center and streams or

migrates them to GCP
● To deploy the Backend…
○ Download the OVA
○ Choose Deploy OVF
○ Specify the host, disk, and network settings
○ Provide the token generated by the Migrate for Compute Engine Manager

● The Backend size affects how many VMs can be

migrated at once
○ Small (2 vCPU, 4GB RAM) - <100
○ Large (4 vCPU, 8GB RAM) - 100+

You download to the OVA where you are accessing the vCenter Web UI. You will
upload the OVA file to the vCenter appliance as part of the deployment process.

You create the token in the Migrate for Compute Engine Manager UI, and it's good for
up to 90 minutes. You then copy the token from the UI and paste it into the OVF
deployment wizard.
 VMware user and role

● Migrate for Compute Engine requires a user with appropriate privileges

○ Create a role with just the required privileges
○ Create a user account for Migrate for Compute Engine and assign the role to
the user

● Migrate for Compute Engine provides a PowerShell script to create the

role for you
○ The current downloadable script is missing a privilege
○ You can modify the script of manually tweak the role once created to include
the Global > Cancel task privilege

● Create the user in Administration > Users and Groups

● Assign the role to the user in Administration >
Global Permissions

You can do the user creation, role creation, and role assignment using the
administrator account, or any other account with appropriate permissions.

You could configure Migrate for Compute Engine to use a full administrator account,
but that's not consistent with the principle of least privilege.

The downloadable script can be found here: https://storage.googleapis.com/Migrate

for Compute Engine-release/V4.2.0/vSphereRole/Migrate for Compute
Engine.vSphere.Service.Role.zip. Unfortunately, it fails to include one permission.
You can either edit the script before running, and include the Cancel Task in the in
the $privs_for_vsphere_role assignment or run the script as is, then manually add the
Global.Cancel Task permission to the role definition.
 vCenter plugin

● Enables operations and

monitoring in the vCenter UI
○ Accessed via the Datacenter
context menu

● Installed via the Migrate for

Compute Engine Manager
● Associated with the
Migrate for Compute Engine user

Once the Migrate for Compute Engine Backend has successfully connected and
registered with the Migrate for Compute Engine Manager on GCP, you need to
register and deploy the Migrate for Compute Engine VMware vCenter Web Client
Plugin. This enables Migrate for Compute Engine management operations and
monitoring in the vCenter UI.

Important: Each Migrate for Compute Engine vCenter plugin can communicate with
only one Migrate for Compute Engine Manager per vCenter server. When
administering multiple vCenter servers in Linked Mode, deploy one Migrate for
Compute Engine Manager per cluster. Then register the Migrate for Compute Engine
vCenter Plugin with each vCenter server from the corresponding Migrate for Compute
Engine Manager.
 Cloud extensions

● Comprised of a pair of edge node VMs

running in two zones
● Responsible storage streaming to
migrated VMs
● Nodes serve workloads while
providing backup for each other
● Size dictates # concurrent migrations
○ Small supports 10-15 VMs
○ Large supports up to 50 VMs

● You can use multiple extensions

A Cloud Extension is a conduit for VM storage between two hosting environments,

such as:

1. An on-premises data center and GCP

2. AWS and GCP

A Cloud Extension uses a dual-node active/passive configuration for high availability;

each node serves its own workloads while providing backup for the other. Health
checks are used to ensure the extension is functioning.

Each Cloud Extension supports 10–50 concurrent VMs. Note that these are soft
limits, and actual performance will vary based on various factors.

You can run more than one Cloud Extension simultaneously to handle a larger
migration. You would also typically install a CE for each region you will be migrating
to.

The total number of Cloud Extensions necessary for a migration is a function of the
total number of VMs divided by the capacity of the Cloud Extension. For example, for
a migration of 1000 VMs, Migrate for Compute Engine recommends using five Cloud
Extensions, each hosting 50 VMs. The migration would use these Cloud Extensions in
four waves.
Cloud Extensions are created and configured either using the Migrate for Compute
Engine vCenter plug-in or the Migrate for Compute Engine Manager.

Cloud Extension VMs stop if idle for 60+ minutes. Extensions are considered idle if
there are no VMs running in cloud. If Extensions are stopped, migration operations
will take a little longer as they must wait for extension to start before the operation can
be performed.
 AWS source cloud configuration

● Settings configured in Migrate for Compute Engine Manager using the

apiuser account
● Migrate for Compute Engine needs IAM credentials to call AWS APIs
○ User account with programmatic access
○ Group membership with required permissions

● Once IAM has been configured in AWS, you need to create a Cloud
Credential object in Migrate for Compute Engine Manager
● Cloud Details objects are also created in Migrate for Compute Engine
Manager
○ Define credentials to use, region, VPC, subnet, etc.

https://cloud.google.com/migrate/compute-engine/docs/4.8/how-to/migrate-aws-to-gc
p/aws-prerequisites
https://cloud.google.com/migrate/compute-engine/docs/4.8/how-to/migrate-aws-to-gc
p/configure-aws-as-a-source

The credential object will have AWS user access and secret keys

Settings to Cloud Details object include…

- Name
- Credentials
- Region
- VPC
- Security Group
- Worker subnets
 Be careful of...

● Inadequate network access

○ Migrate for Compute Engine Manager to Backend
○ All the intra-DC communications

● Streaming throughput limitations

○ Streaming throughput from vSphere = 20-30MB/sec/vmdk

● Insufficient permissions in vSphere and AWS

● Max of 60 VMDKs or RDMs per ESXi host
● IDE virtual disks are not supported (convert to SCSI)
● VMs can only be migrated to same VPC that the manager is running on

https://cloud.google.com/migrate/compute-engine/docs/4.8/resources/known-issues

Typical storage throughput - Due to vSphere Storage API limitations, throughput per
on-premises VMDK is limited to about 20-30MB/sec. When workloads are highly
concentrated on a single disk, initial performance may be limited due to increased in
latency back on-premises. This situation typically resolves itself within minutes, as
soon as a sufficient amount of data is cached in the cloud.

Maximum concurrent read sessions per ESX host - Due to vSphere Storage API
limitations, the number of storage sessions per ESX host is constrained. Migrate for
Compute Engine limits the number of VMDKs or RDMs that can be connected to VMs
in the cloud to 60 per ESX host. Multiple ESX hosts may be used. These hosts can be
of minimal specs.

If you need to migrate VMs to multiple VPCs, you can perform multiple installations of
Migrate for Compute Engine Manager. However, you can only have one connection
from a vCenter host to a Migrate for Compute Engine manager, so you'll need to
reconfigure source environments between migrations.
 Lab 9
Installing Migrate for Compute Engine
Agenda
Introduction

Migrate for Compute Engine concepts and requirements

Migrate for Compute Engine installation

Basic migration operations with Migrate for Compute Engine

Automating migrations with Migrate for Compute Engine

Application and special case migrations

Summary and next steps

 Migrate for Compute Engine migration operations

Migrate Prepare to
Model Test Run-in-cloud
storage detach Detach

Determine VM Run application Move VM to the Detach from

Continue production
relationships and clones in the cloud, cloud, operational in Write data from Migrate for
operations while data
dependencies in without affecting minutes, while data cache to native Compute Engine
transfers in the
the automation production data or is accessed from GCP disks and run natively in
background
runbook uptime cache the cloud

Run on Prem
/ Cancel

Optional “safety
net” that allows
reverting to an
on-prem VM

Modelling, runbooks, and automation will be covered in the next section. This section
focuses on the other operations represented in the diagram.
 Pre-migration testing with clones
Datacenter

● Validate migration viability before VMWare VM Snapshot

disrupting the workload

● VMware snapshot created without Write
Isolation
disruption
● GCP VM ready in minutes, using streaming
Edge Node
○ Write isolation storage policy Compute Engine

Cloned VM
● Benchmark latency, throughput, errors, etc. Compute Engine

Caching

● Take care to "isolate" cloned workload so Cloud Storage

that it doesn't impact production

● Delete clone when testing is complete

Original VM is undisturbed and continues to operate in VMware datacenter. The

snapshot becomes the source of the streaming data for the cloned VM.

A clone VM is started in GCP, boots using a proprietary boot image, gets data via
streaming. Cloned VM will boot in approximately 10 minutes. The storage policy is
write isolation, which means that any changes to VM-connected storage are cached
locally in GCP, and never replicated back to original VM. This allows for a certain level
of isolation in your testing.

What might you be testing for?

- Test to make sure latency between your GCP VM and required services is fine
- Test to ensure that your VM size selection in GCP offers sufficient throughput
for your app
- Test network connectivity and throughput
- Test to make sure applications don't break
While you can test with synthetic benchmarks, probably the best way to test would be
to extend your test environment so that it can run standard suites against your clones.

Keep in mind side-effects that might occur when testing clones. While VM storage
changes won't affect production, other application activities on your clone might
impact production:
- Changes to production DB
 - Messages sent via message broker might get handled by production services
- Calls to other microservice might get handled by production services
- Network traffic generated might impact production networks

It's your responsibility to ensure your testing is isolated and doesn't impact product.
 Running in the cloud Migrate for Compute
Engine RPM

Datacenter

● Replaces on-prem VM with GCP VM Windows

Linux VM
VM
○ Streams data from on-prem disks
○ Downtime is required
Up and running in 10-15 minutes
Write Back
○

● VMs must modified to run in cloud

○ Windows modifications handled Edge Node
Compute Engine
automatically
RIC VMs
○ Linux VMs require an RPM installed before Compute Engine

migration Caching
Cloud Storage

● Storage migration, detaching/reversion

happen later

When running in cloud, Migrate for Compute Engine…

- Takes ownership of VM
- Marks VM as managed by Migrate for Compute Engine
- Shuts down the VM and takes a snapshot
- Mounts VM disks using VMware APIs
- Establishes channel to extension edge nodes
- Creates a GCP VM
- Prepares an image to run in cloud (modifications, connection with streaming
channel)
- Boots VM
Modifications made for Windows VMs
- Network driver installation
- Network configuration changes
- iSCSI service boot start
- iSCSI service tuning
- License/edition changes
- iSCSI related changes
- VMware Tools are disabled
- Change page file location
 - Ensure hibernation is disabled
- Change recovery options
- Enable RDP

Modifications made for Linux VMs

- Enable boot in-cloud integration
- Enable serial console log integration
- GCP-specific changes
- Disable "hostonly" dracut initrd builds
- Rebuild initrd (dracut / mkinitrd)
- The following modifications are dynamically applied
- in the cloud:
- Remount mounts with _netdev option to support proper
- shutdown sequence
- Remap swap files
- Perform network configuration adaptation where applicable
- Start Migrate for Compute Engine keep-alive service
- Perform disk optimizations
When doing migration, you get to select target subnet, network tags, service account,
internal ip address as ephemeral or static, external ip address.
 Storage migration

● Makes the GCP VM independent of its source

○ Caches all data in GCP
○ Preparatory step for full migration

● Can be started at any time

● Time required depends on amount of data and available bandwidth
○ Typically at least a couple hours
○ Deprioritized relative to streaming operations

● Can be monitored
○ Progress via Migrate for Compute Engine Manager
○ Bandwidth consumption via vCenter

https://cloud.google.com/migrate/compute-engine/docs/4.8/how-to/migrate-on-premis
es-to-gcp/migrating-on-premises-storage
 Preparing to detach
Datacenter

● Started after VM is fully cached VM Disk

Migrate
Backend

● Moves data from Migrate for Compute

Engine cache to native GCP persistent Write Back

disks that match source disks

○ You can specify PD type
Edge Node
● Uses an exporter instance to populate Compute Engine

persistent disk and continue disk Exporter

synchronization until detach

Compute Engine

Caching

When sufficient progress has been made,

Cloud Storage
● Name
Persistent Disk
VM is marked as Ready to Detach

https://cloud.google.com/migrate/compute-engine/docs/4.8/how-to/vm-operations/det
aching-a-vm

Exporter is an n1-standard-2 instance.

You are offered choice of standard or SSD persistent disk types when creating
the GCP native PDs.
 Migrate vs. Run in Cloud

● Migrate performs the following…

○ Run in Cloud
○ Start Storage Migration
○ Prepare to Detach

● Why would you use three-step

manual process vs. migrate?
○ If you expect not to detach for
an extended period, could save
costs

By not performing the Prepare to Detach operation, you avoid building and
paying for the exporter instance.
 Detaching

● Performed after Preparing to Detach is complete

● Offers chance to change instance type/size
● Entails downtime; must be scheduled
○ VM shuts down
○ Last sync is performed
○ Native disks are attached to VM
○ VM boots
○ Takes about 5-10 minutes

● When detach complete, perform workload validation

○ Cleanup or roll back
○ Note that data is no longer being synched back to on-prem

https://cloud.google.com/migrate/compute-engine/docs/4.8/how-to/vm-operations/det
aching-a-vm

Any changes to vm-attached storage after detach will be lost if you cancel the
detach and/or run on prem.

Validation entails final checks to ensure the workload is functioning as

expected. You should have done initial testing using clones, but final
performance and configuration will be slightly different with detached VMs
(native GCP-disks rather than streaming, etc.) and is worth checking.
 Cleaning up
Datacenter

● Performed after VM is detached Migrated

VM
Backend

● Cached data is cleared from GCS

● Source VM no long managed by Migrate
for Compute Engine
○ It's powered off Edge Node

Don't turn it on - archive it

Compute Engine
○
Migrated VM delete cache
Compute Engine
Caching
Cloud Storage
Name
Persistent Disk

https://cloud.google.com/migrate/compute-engine/docs/4.8/how-to/vm-operations/det
aching-a-vm#start-detach-cleanup

If you choose to force clean up, it will complete the action without waiting for
internal subtasks to complete (deleting object store, talking to cloud
extension).
 Cancel Detach and Run On-Premises
Datacenter

● You may decide not to proceed with Migrated

Backend
VM
completing migration at a given time
● Cancel Detach deletes the GCP PDs and
goes back to fully cached state
○ Can be done anytime before cleanup
○ There is downtime of < 5 minutes Edge Node
Compute Engine

● Run On-Premises reverts the migration Migrated VM re-establish cache

steps already performed

Compute Engine
Caching

○ Deletes GCP VM and disks Name

Cloud Storage

○ Moves data back on-prem as appropriate Persistent Disk

○ Does not restart the VMware VM

https://cloud.google.com/migrate/compute-engine/docs/4.8/how-to/migrate-on-premis
es-to-gcp/migrating-on-premises-storage

You might choose to cancel detach but not Run On-Premises if there are
problems with detached machine that didn't exist when running in cloud, and
you want to return to a steady state, but not return to datacenter (which might
entail unwanted on-prem configuration changes).

If you choose to force a Run On-Premises, when using the write-back storage
policy, the latest consistency checkpoint is used, and changes made after the
checkpoint are abandoned. This might be necessary if the cloud cache is
inaccessible.
 Miscellaneous operations

● Instance management is done via Migrate for Compute Engine

Manager or vCenter; avoid using GCE UI directly
● Power operations
○ Power on
○ Power off
○ Restart

● Reconfiguration operations
○ Change instance type
○ Change storage policy
○ Performed via wizard in vCenter Web Client

https://cloud.google.com/migrate/compute-engine/docs/4.8/how-to/vm-operations/pow
ering-on
https://cloud.google.com/migrate/compute-engine/docs/4.8/how-to/vm-operations/rec
onfiguring-a-vm

Note: A reboot is required when changing the instance type. The VM's private
IP address and other identifiers remain the same.

You can change the storage policy from write-back mode to write-isolation
mode and vice versa. A typical reason for changing the storage mode is to
promote an instance from a test environment to production.

If you change the storage policy from write-isolation mode to write-back mode,
the data is written back to on-premises. After the data is synchronized, you can
then run the VM back on-premises.

Warning: If you change the storage policy from write-back mode to

write-isolation mode, the edge node stops transferring the data from the cloud
instance.
Caution: All state on VMs in write-isolation mode is lost if machines are moved
back on-premises.

If you do a power off in the GCP Console, it will trigger a Stop in Cloud
operation in vCenter/Migrate for Compute Engine. However, if you start a VM
via the console, Migrate for Compute Engine - which consider the VM stopped -
will immediately initiate a Stop in Cloud action and turn it back off. It's best to
start/stop VM from vCenter or Migrate for Compute Engine Manager.
 Migrating from AWS

Available operations Migration process

● Run-in-Cloud ● Stops the source VM in AWS

● Storage Migration
● Move back
● Prepare to detach
● Detach
● Cleanup
Write isolation mode only!
● Creates the Migrate for Compute Engine VM
Importer at AWS
● Detaches the EBS volumes from the source VMs
and attaches them to the Importer
● Creates an instance in GCP
● Streams data from the Importer to the GCP Cloud
Extension
● Terminates the Importer and re-attaches the disks
to the source VM

https://cloud.google.com/migrate/compute-engine/docs/4.8/how-to/migrate-aws-to-gc
p/migrating-aws-vms

Data is not synched back into AWS; if you perform a Run On Premises
operation, you will lose any changes to local storage that have occurred in the
cloud.

At the end of the Run-in-cloud process, the original instance in AWS is intact
and powered off.

You may perform AWS migrations manually or via automation (covered in next
section).
 Migrating from Azure

Available operations Migration process

● Run-in-Cloud ● Stops the source VM in AWS

● Storage Migration
● Move back
● Prepare to detach
● Detach
● Cleanup
Write isolation mode only!
● Creates the Migrate for Compute Engine VM Importer at
Azure
● Takes a snapshot from the source VM disk
● Creates a data disk from source VM snapshots and
attaches it to the Migrate for Compute Engine importer
● Creates an instance in GCP
● Streams data from the Importer to the GCP Cloud
Extension
● Terminates the Importer and cleans up

https://cloud.google.com/migrate/compute-engine/docs/4.8/how-to/migrate-aws-to-gc
p/migrating-aws-vms
https://cloud.google.com/migrate/compute-engine/docs/4.8/how-to/migrate-azure-to-g
cp/migrating-azure-vms

Data is not synched back into AWS; if you perform a Run On Premises
operation, you will lose any changes to local storage that have occurred in the
cloud.

At the end of the Run-in-cloud process, the original instance in AWS is intact
and powered off.

You may perform AWS migrations manually or via automation (covered in next
section).
 Be careful of...

● Linux workload without RPM installed

● Technical requirements not in place
● Saturating your interconnect
● Using the wrong migration operation (e.g., use offline only for legacy OS)
● Running out of storage capacity in on-prem for write-back snapshots
○ Especially important if the application is write heavy

● Occasionally, the recommended instance-type is wrong

○ Close dialog and start again

● VMs with multiple NICs

Migrated VMs will always be provisioned with a single NIC. You will need to do
post-migration configuration to add additional network interfaces.
 Lab 10a
Migration Operations with Migrate for Compute
Engine
Agenda
Introduction

Migrate for Compute Engine concepts and requirements

Migrate for Compute Engine installation

Basic migration operations with Migrate for Compute Engine

Automating migrations with Migrate for Compute Engine

Application and special case migrations

Summary and next steps

 Goals for automation

Move batches of VMs together

Optimize velocity, correctness, consistency

Eliminate toil

Moving batches will be faster than moving individual machines.

Automated tools can ensure that each machine is moved the same way. This means
either all the machines are moved successfully, or they fail in the same way - which
makes it easier to diagnose and resolve.

Automation also significantly reduces the amount of hands-on time required from
operations staff during migration.
 Scheduling with sprints

● The overall migration project will be broken Migration project

into sprints
● A sprint will move all the VMs for one or more
apps Sprint 1 (FM): Sprint 2:
Internal Apps CI/CD servers
● Sprints will be scheduled according to priority
○ First mover goes...first!
Sprint 3: Sprint 4:
Web Servers CRM
● Typically a sprint will include
○ Migration, testing, detaching
Final Assess Final Plan
○ Review of results
○ Optimization of process Clone/Test Migrate
○ Preparation for next sprint
Detach/Clean Review/Ready

Sprints will obviously be ordered according to the priorities for the project overall.

One sprint will typically comprise all the VMs for a given app or set of apps.
 Organizing waves of machines in runbooks

● A sprint may include multiple applications Migration project

being moved
● One way to organize machine migration is
to have one wave per application Sprint 1: Sprint 2:
Internal Apps CI/CD servers
● Migrate for Compute Engine manages
waves with runbooks and jobs
Sprint 3: Sprint 3:
Web Servers CRM
● Runbooks details migration settings per VM,
and specify ordered groups
● Jobs are specific migration operations to Wave 1:
Wave 2:
go/who
be performed against a runbook go/percent

A sprint will often be broken into waves. For purposes of the class, we define a wave
as the machines associated with an application.

A runbook is a CSV file with a list of machines to migrate, ordering information, and
per-machine migration settings.

Migrate for Compute Engine creates configuration objects called Wave, populated via
a runbook (you will operate against the machines in the runbook as a unit).

A job is a specific migration operation performed against a wave (e.g. run in cloud).
 Working with Runbooks

● Runbooks are CSV files with VM migration settings

○ Generated by querying AWS or vCenter or exporting from other tools
○ Edited with any text editor or spreadsheet
○ You will need to provide per-VM settings beyond what's discovered

● Run Groups control the order of migration

○ All VMs in a group are migrated in parallel; groups are migrated serially

● Other settings control target VM configuration and extension

https://cloud.google.com/migrate/compute-engine/docs/4.8/reference/runbooks/

Other tools that can generate runbooks include Stratozone and any custom tooling
that teams build to write CSV files conforming to the Runbook schema.

The runbook includes configuration settings for…

- RunGroup
- BlockOnFailure
- VmID
- VmName
- SourceCloudDetails
- OSType
- license:os
- NumCPU
- MemoryGB
- NumDisks
- ProvisionedSpaceGB
- TargetCloudExtension
- TargetEdgeNode
- WriteIsolation
 - TargetInstanceType
- TargetInstanceName
- TargetSubnet
- TargetPublicIP
- GcpEphemeralPublicIp
- GcpProject
- GcpNetworkTags
- GcpInstanceServiceAccount
- GcpDiskType
- ProbeTCPPort
- ProbeWaitMinutes
- tag:* columns
- AffinityIN
- AffinityNOT
- RestartOnFailure
- HostMaintPolicy

The runbook generated by querying AWS or vCenter will require significant editing to
make it usable. At a minimum, you will need to set a RunGroup for at least one VM,
and set the targetinstancertype for any VMs assigned to run groups.
 Rightsizing VMWare VM
(2 vCPU; 7GB RAM)

● Runbooks must contain n1-Standard-2

TargetInstanceType settings for each VM

Runbook:
● Rightsizing decisions Assess/Plan phases can PerfOptRec_type_1
be plugged into your Runbook
Performance-based recommendation

● Migrate for Compute Engine also can make

rightsizing recommendations VMWare VM
(2 vCPU; 7GB RAM)
○ Performance-based uses current allocations 50% utilization
(VMware, AWS, Azure)
n1-Standard-1
○ Cost-based also includes actual usage, based
on monitoring data (VMware) Runbook:
CostOptRec_type_1

Cost-based recommendation

https://cloud.google.com/migrate/compute-engine/docs/4.8/concepts/planning-a-migra
tion/cloud-instance-rightsizing

Right-sizing suggestions are generated in the Wave management screen of the

Migrate for Compute Engine Manager UI.

Performance-based recommendations do not require any monitoring. Cost-based

recommendations require that you enable vCenter monitoring the VMs, and this is
enabled via the Right-Sizing action in the Wave management UI. It's recommended
that you monitor for at least 7 days to generate quality cost-based recommendations.
A full business cycle is ideal (this may be a day, week, month). Recommendations will
only be returned for machines assigned to a run group (not -1).

The output of the Right-Sizing action is a new Runbook file that includes a OptRec
column that contains the recommendations. If you wish to use the recommendations,
you must copy the values from this column into the TargetInstanceType column.

Recommendations will go into a series of columns named PerfOptRec_type_x or

CostOptRec_type_x. There will be three recommendations provided for each type of
recommendation. Estimated VM costs (excluding disk and network use) are also
provided.

There's no one-size-fits-all practice for choosing the right size. Tools will make
recommendations for peak loads, 99% loads, etc. You will have to work with the
customer to determine the desired approach. Once you've decided, you can configure
the right-sizing as part of your runbook. Keep in mind you can always over-provision a
bit here, and then during the optimize phase take GCP's recommendations to adjust
vm sizing.
 Migrating Waves
Runbook

● Create a Wave by importing a Runbook

● Validate the Wave Migrate for Compute Engine
Manager
● Start a job, executing an operation again
Runbook
Wave
● Full migration will require multiple jobs
○ Each job is a migration operation from the
migration lifecycle Validate Wave
Job 1:
Migrate

Job 2: Job 3:
Detach Cleanup

https://cloud.google.com/migrate/compute-engine/docs/4.8/how-to/organizing-migratio
ns/creating-new-waves
https://cloud.google.com/migrate/compute-engine/docs/4.8/how-to/organizing-migratio
ns/creating-aborting-jobs

Before taking any action on a wave by creating jobs, the wave must be validated.
Validation finds semantic errors such as invalid or nonexistent:

- VM IDs
- Connectivity from GCP to the vSphere environment or AWS
- Cloud Extension IDs
- GCP instance types
- GCP cloud details
- GCP subnets
- GCP projects
- GCP service accounts

Migrate for Compute Engine supports custom service accounts only. Validation fails
with built-in GCP service accounts.

For sole-tenant and Windows Bring Your Own License (BYOL) VMs, Migrate for
Compute Engine performs the following additional validations:
 - Whether the keys and values for node affinity exist.
- Whether the selected instance type has more than two cores.
- Whether the Host Maintenance Policy agrees with the type of license selected.
- Validation must complete without errors in order to add jobs.

To perform a validation:

- Click Action > Validate.

- To validate the runbook, click Yes.

The validation may take several minutes to complete. When it completes, a validation
status column appears in the table. If a validation fails, click Failed within the row to
see the failure messages.

If validation fails, fix your runbook and reload it, or change your environment settings,
for example, Cloud Details in Migrate for Compute Engine Manager. Then re-run the
validation until it succeeds.
Monitoring Waves

● Wave details page shows status of each VM

○ VMs unassigned to a wave are viewable too
○ The console log for a VM can be viewed

● VMs can also be managed

○ Start/Stop/Reboot
○ Move Back (Run On-Premises)
 Other tools for automation

● All Migrate for Compute Engine UI operations can be executed via

PowerShell
○ Download, install, and import modules
○ Connect to Migrate for Compute Engine appliance
○ Execute operation cmdlets

● REST APIs allow for automation and integration with third-party tools
○ Manage Cloud Extensions, VMs, Tasks, Runbooks
○ Protected by basic HTTP authentication
○ Easy exploration via https://<Migrate for Compute Engine
ip>/swaggerUI/

https://cloud.google.com/migrate/compute-engine/docs/4.8/how-to/automating-migrati
on/installing-powershell-module
https://storage.googleapis.com/Migrate for Compute
Engine-release/V4.2.0/Latest/Migrate for Compute Engine.PowerShell.4.2.0.msi

To connect to the Manager, use Connect-Migrate for Compute EngineManager.

- User is apiuser
- Password is whatever you set during installation
cmdlets include:
- Get-VelosCe
- MoveVelosVm
- Get-VelosTask
- Get-VelosVM
- Invoke-VelosMigration
- Start-VelosDetach
- Stop-VelosDetach
- Start-DelosDetachCleanup
- Stop-VelosTask
- Get-VelosCeSecurityGroup
- Get-VelosCredentials
 - Get-VelosRunbookJob

https://storage.googleapis.com/Migrate for Compute

Engine-release/V4.2.0/REST_API/Migrate for Compute EngineAPI.html
https://storage.googleapis.com/velos-documentation/Migrate for Compute
EngineAPI_Runbook.html

REST API can be called by vRA, Ansible, in-house tooling, etc.

Be careful of...

● Runbook rows without RunGroup or TargetInstance type values

● Using only one Edge Node
● RunGroups failing (use BlockOnFailure)
● Inconsistencies in Runbook (use populate with cloud extension defaults)
 Lab 10b
Migration Operations with Migrate for Compute
Engine
 Lab 11
AWS and Automated Migrations
 Lab 10c
Migration Operations with Migrate for Compute
Engine
Agenda
Introduction

Migrate for Compute Engine concepts and requirements

Migrate for Compute Engine installation

Basic migration operations with Migrate for Compute Engine

Automating migrations with Migrate for Compute Engine

Application and special case migrations

Summary and next steps

 Migrating Apps vs. VMs

● Companies typically think in terms of moving applications (or business

units, or datacenters)
○ Moving a VM is a key element, but not the final goal

● The strategy for moving an app will depend on the app and the
requirements of the business
Criticality

Batch financials Customer-facing apps

Batch report of test results Internal apps

Sensitivity to downtime

Green = take the process down, move everything

Yellow = take it down and move everything, but…

1. critical to get it right
2. dry-runs
3. testing
4. fallback strategy
Orange/red = plan for minimized or zero downtime
1. Load balance across on-prem and GCP, and migrate in pieces
 Migrating in pieces

● For stateless apps, you can load balance across the interconnect
○ Load balancers in front of on-prem and GCP instances
○ DNS load balancing sending traffic to both load balancers
○ Minimizes downtime

● For multi-tier apps, you can migrate tiers in order

○ Use RunGroups or Waves to manage sequencing
○ Consider replicating database (not migrating) to cloud first
○ Some refactoring may be required

● An application's sensitivity to latency will affect decisions about whether

it moves all-at-one, or in pieces
○ Will it function well given order of magnitude increases in latency when
accessing DB or supporting microservices across the interconnect?

1.
 Offline migration install package
Windows Server 2008
32-bit
● Enables migration of operating systems that
don't support streaming
Offline Migration
○ Windows Server 2003
○ Window Server 2008 (non-R2)
○ Ubuntu 12 Run in cloud /
Shut down VM
stop
● The process is automated and will
○ Shut down on-prem VM
Storage Detach/
○ Run-in-cloud, then shut off cloud instance migration cleanup
○ Perform full storage migration, detach, cleanup
○ Power on cloud VM
Start VM
● Special preparation required for some OSes

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.

During the offline migration process, all storage migrates to the cloud first, and
then the VM starts.

Another use case for offline migration is storage-only migration for VMs that
aren't supported by the cloud provider. These are typically VMs with older
operating systems, for example Red Hat 4. With storage-only migration, you
can migrate volumes and then reattach them to a VM with a supported OS.

For Ubuntu 12.x: Edit /etc/network/interfaces and change the primary

interface name to eth0 and set it to DHCP:

For Windows Server 2008 non-R2, 32-bit: Windows Server 2008 32-bit requires
package installation before starting offline migration.
https://storage.googleapis.com/Migrate for Compute
Engine-release/V4.2.0/Windows-2008R1-Drivers/Windows%202008R1%2032b
it%20Drivers.zip
 Physical server migration concepts
Migrate for Compute Engine
● Physical server can be migrated much like VMs
Connector ISO
○ VM is created in GCP
○ Data is streamed from physical server
○ Storage can be migrated, VM can be detached, Physical Server
(supported OS)
etc.

● Servers boot using Migrate for Compute

Engine Connector image Create stub VM Map storage

● The connector maps local storage into

VMWare and creates a stub VM Migrate VM (via Detach/
stub) cleanup
○ VMware host is an iSCSI client; server being
migrated is an iSCSI target

● Migration is invoked manually or via Wave

https://cloud.google.com/migrate/compute-engine/docs/4.8/how-to/prepare-vms-serve
rs/physical-servers

In addition to migrating virtual machines with common operating systems to

Google Cloud Platform (GCP), Migrate for Compute Engine also allows for
migration of physical servers or VMs running any OS that is supported by GCP.
Migrating physical servers has the same prerequisites as migrating VMware
VMs.

You can migrate a physical server to the cloud by booting a Migrate for
Compute Engine Connector ISO image into RAM from a virtual or physical DVD
ROM/CD ROM device.

The Migrate for Compute Engine connector maps the local storage of the
physical server and creates a stub VMware VM as a management object for
Migrate for Compute Engine cloud migration operations.

The migration proceeds the same as the migration of other VMs, except that
migrations are performed in write-isolation mode, where data changes made in
the cloud are not synced back on-premises.

Note: The stub VM only allows Migrate for Compute Engine to manage the
physical server's migration via vSphere, and does not perform operations
beyond that. It has no network interface and minimal CPU and RAM.
 Physical server migration requirements

● Supports SAS, SATA, SSD disks and SAN

volumes mounted on physical HBAs
Physical Server (4GB RAM;
○ PATA and IDE disks are not supported CD-ROM; no PATA/IDE)

● Server requires a minimum of 4GB of RAM

● Physical or virtual CD-ROM drive
○ iDARC/iLO/RSA are supported

● The ESXi host used for the stub VM should be

attached to at least one non-NFS datastore ESXi Server (non-NFS
datastore; iSCSI adapter)
● ESXi host needs an iSCSI Software Adapter

https://cloud.google.com/migrate/compute-engine/docs/4.8/how-to/prepare-vms-serve
rs/physical-servers

System requirements
- Disk types: supported include SAS, SATA, SSD, virtual disks presented
by the hardware controller, and SAN volumes mounted on physical
HBAs. PATA/IDE disks are not supported.
- RAM: A minimum of 4GB RAM is recommended. For machines with less
than 4 GB RAM, press any key during the boot splash screen (the screen
with the keyboard icon), and choose the Migrate for Compute Engine
Connector low memory option from the menu. This option reads
on-demand from the CD image.
- DVDROM/CDROM: A physical DVDROM/CDROM or virtual CDROM from
which to boot the Migrate for Compute Engine Connector ISO.
 Multiple IP addresses

● Migrated Linux VMs can use GCP

Alias IP Ranges to leverage multiple
IP addresses
● Migrate for Compute Engine supports
ranges of up to 32 addresses
● Set metadata at project or instance
level (apply-alias-ip-ranges:true)
● Configure the Alias IP Ranges on the
instance (manually or automated)
● Once the VM is restarted, it will make
use of the multiple addresses

You can set the metadata properties in waves by configuring tag columns in the
runbook. You will have to configure the alias ranges manually or with some
extra-Migrate for Compute Engine automation.
 DNS configuration

● In many cases, you want VMs to use a

corporate DNS server, instead of the VPC DNS
VPC DHCP
default VPC resolver Resolver

○ Especially in Active Directory domains

● Migrate for Compute Engine can override

the default GCP DNS settings on migrated Migrated VM

instances
○ dns-servers
○ dns-domain-suffixes
Metadata Corp DNS Server
○ dns-domain-name (Windows)

● Configuration is done via metadata

https://cloud.google.com/migrate/compute-engine/docs/4.8/how-to/networking/using-e
xternal-dns

Google Cloud Platform (GCP) VPC networks have an internal DNS service but do not
automatically support configuring external DNS for a VM. Enterprises, however, may
prefer to manage their own DNS servers and thus need to configure external DNS on
migrated VMs.

Migrate for Compute Engine provides a way to set and control the external DNS
settings of migrated VMs. To do this, you configure DNS settings in the GCP project
(and region) using GCP project metadata. These settings are applied to new VMs as
they are migrated.

Note: DHCP retrieves the primary IP address, subnet masks, gateway, and other
necessary network details.
When empty DNS metadata is provided (such as default-dns-servers = ""), DHCP
overwrites the DNS configuration.

Using VMs with a region setting

1. If your VMs have a specific region setting, add the following key-value pairs in
the Metadata page:
a. Key: {region_name}_dns-domain-name Value: : mydomain.com -
represents the connection-specific DNS suffix in Windows clients.
 a. Key: {region_name}_dns-servers Value: : {comma separated list of
IPs}- represents the list of DNS servers.
b. Key: {region_name}_dns-domain-suffixes Values: mydomain.com,
myseconddomain.com - represents the list of DNS suffixes to add to
Windows and Linux machines.
2. When you're done, click Save.

Using VMs without a region setting (default configuration)

1. If your VMs don't have a specific region setting, add the following key-value
pairs in the Metadata page:
a. Key: default_dns-domain-name Value: mydomain.com
b. Key: default_dns-servers Value: {comma separated list of IPs}
c. Key: default_dns-domain-suffixes Value: mydomain.com,
myseconddomain.com
d.
2. When you're done, click Save.

You can set the metadata properties in waves by configuring tag columns in the
runbook.
 Linux and premium OS licenses

● There are two licensing options when migrating VMs running Red Hat
Enterprise Linux or SUSE Linux Enterprise Server
○ BYOL licensing
○ Premium OS licensing via Marketplace

● Migrate for Compute Engine can enable Marketplace licensing when

migrating the VM
○ Configure VM rows in Runbook
○ Populate the license:os field

https://cloud.google.com/migrate/compute-engine/docs/4.8/how-to/prepare-vms-serve
rs/using-premium-os-licenses

With BYOL - you are responsible for managing the licensing, and you pay full license
fee regardless of how much you use the VM.

With Marketplace licensing, you only pay a pro-rated amount for the software license
based on VM usage.

license:os field values can be:

● RHEL 6 - https://www.googleapis.com/compute/v1/projects/rhel-cloud/global/
licenses/rhel-6-server
● RHEL 7 - https://www.googleapis.com/compute/v1/projects/rhel-cloud/global/
licenses/rhel-7-server
● SLES 11 - https://www.googleapis.com/compute/v1/projects/suse-cloud/global/
licenses/sles-11
● SLES 12 - https://www.googleapis.com/compute/v1/projects/suse-cloud/global/
licenses/sles-12
Microsoft BYOL licensing with Migrate for Compute
Engine
● VMs are migrated with Waves/Runbooks
● Configure the columns within Runbook

Column Value

license:os Supported BYOL license string

SoleTenancy-NodeAffinity:[key] Node affinity groups to use

SoleTenancy-NodeAffinityNot:[key] Node affinity groups to avoid

SoleTenancy-RestartOnFailure true/false (depending on preference)

SoleTenancy-VmHostMaintenancePolicy terminate
 Adaptations

● Migrated VMs require changes to function correctly in GCP

● Migrate for Compute Engine handles many changes automatically via
adaptations
○ Admins can also create custom adaptations

Linux VM Windows VM

C:\Program
Migrate for Compute Engine
Files\velostrata\System
RPM
Scripts

C:\Program
/opt/velostrata/actions/
Files\velostrata\User
<phase>.rules
Scripts

/etc/velostrata/actions/
<phase>.rules

https://cloud.google.com/migrate/compute-engine/docs/4.8/concepts/planning-a-migra
tion/vm-adaptations

This section describes OS adaptations performed by Migrate for Compute Engine, as

well as modifications made to Windows and Linux VMs for the run-in-cloud and
detach operations.

VM changes performed automatically

Migrate for Compute Engine prepares Linux VMs for booting in GCP using an
automatically installed package. Changes are activated only when detecting a
run-in-cloud operation, and the package can remain installed after the VM has been
migrated. If the package is uninstalled, all changes are reverted.

The set of changes made to the system are:

- Enable booting on GCP.

- Enable serial console.
- Cloud-specific changes for the Migrate for Compute Engine storage channel.
- Hardware-specific adaptations for cloud migration.

Modifications for run-in-cloud on Windows VMs

Before moving the Windows VM to GCP, Migrate for Compute Engine shuts down the
VM and takes a snapshot. Migrate for Compute Engine then modifies the networking
and storage drivers to allow the VM to boot in the cloud.

- Install the NETKVM driver for Migrate for Compute Engine.

- Change network configuration.
- System tuning for iSCSI and MPIO access.
- Change license/edition.
- Disable VMware tools.
- Change page file location.
- Ensure hibernation is disabled.
- Change recovery options.
- Enable RDP.
- Deploy the Migrate for Compute Engine framework that allows you to run
custom actions.

Modifications for run-in-cloud on Linux VMs

The Migrate for Compute Engine package is required before migrating.

When you migrate a VM that has VMware tools installed, Migrate for Compute Engine
shuts down the VM gracefully and takes a snapshot of the VM. Migrate for Compute
Engine then modifies the networking and storage drivers to allow the VM to boot on
GCP. These modifications include:

- Changing to the boot sequence (initrd).

- Enabling the serial console.
- Dynamically applying the following modifications in the cloud:
- Moving mount points with the _netdev option to shut down correctly.
- Remappang swap files.
- Starting the Migrate for Compute Engine keep-alive service.
- Performong disk optimizations.
- Changing network configurations, including:
- Removing static IPs and routes: Most migrated systems are preconfigured to
static network environments, which includes pre-defined IPs, gateways,
routes, network cards, etc. Cloud environments, however, only allow DHCP
configuration with network topology managed outside of the VM itself. The
Migrate for Compute Engine package removes all static configuration and
reconfigures the default network interface (eth0) with DHCP.
- Updating the primary IP address of hostname in /etc/hosts: Some applications
 - rely on /etc/hosts to extract the local IP address. The package updates
/etc/hosts with the new IP address to preserve compatibility.
- Making changes specific to GCP, as needed.

Modifications for detaching a Windows VM

In addition to changes made during the run-in-cloud operation, during a detach of a

Windows VM, Migrate for Compute Engine installs the GCP cloud agent.

Modifications for detaching a Linux VM

In addition to modifications made for the run-in-cloud operation, the package tunes
the network configuration after detaching.
 Custom adaptations

● Useful for things like..

○ Installing Stackdriver agents
○ Uninstalling software
○ Stopping service
○ External DNS record registration

● Linux VMs use rules files which specify actions and order
○ One file per phase (on-prem, run-in-cloud, detach)

● Windows VMs use registry entries to invoke scripts during phases

○ Within a phase, tasks are ordered alphabetically
○ Easiest way to configure is using a PowerShell script

https://cloud.google.com/migrate/compute-engine/docs/4.8/how-to/prepare-vms-serve
rs/windows-adaptations
https://cloud.google.com/migrate/compute-engine/docs/4.8/how-to/prepare-vms-serve
rs/linux-adaptations

origin = on-prem
velos = run in cloud
detach = after detach

Rule parameters
The following parameters for rules can be defined in each <PHASE>.rules file:

● NAME: A unique rule name.

● PLATFORM: Cloud or platform to run rule on (any).
● TEST: A test for a file's existence. If a path is specified, the rule is only
executed if the file and directory path exist. This parameter can also be used
to check if the script was already run (by writing a file to indicate it).
● ACTION: Bash script to run or an inline command
● REQUIRES: Optional field for required services for rule to run (currently, only
rc.local is supported).

For Windows systems, Migrate for Compute Engine provides some OS adaptation
scripts by default. You can also provide additional scripts by saving them to this
directory:

c:\Program Files\Migrate for Compute Engine\UserScripts

The registry is updated to run the scripts (also known as UserTasks) on startup
depending on the environment where the VM is running (also known as the
MachineState).

The three options for MachineState are:

● Origin - The scripts run when the VM is in the on-premises environment

● Migrate for Compute Engine - The scripts run when the VM is running in
cached mode.
● Detach - The scripts run after the detach operation.

The tasks are executed sequentially in alphabetical order. If the order of the tasks is
important, use numerical prefixes in the task names, such as 10_ResetWMI and
20_ConfigKMS. Be sure to use absolute paths in the user script because relative
paths won't resolve correctly.

Important: In order for the tasks to be properly configured, scripts must be saved in
the UserScripts directory and the registry keys must be updated. The following section
describes how you can easily do this using an assistance script. Note that only
PowerShell scripts can be used for this purpose.

PowerShell Assistance Script

Migrate for Compute Engine provides a PowerShell module that simplifies installation
of your user script on a relevant VM. The script validates user input to prevent
inconsistent states, copies the user script to the UserScripts directory, and creates a
tree if needed. The PowerShell module also creates the relevant registry keys and
their trees, and fills in the appropriate values.

Module name: Migrate for Compute EngineUserScripts.psm1

Available commands are: Install-VelosUserScript and Remove-VelosUserScript

 Lab 10d
Migration Operations with Migrate for Compute
Engine
 Lab 12
BYOL Licensing and Custom Adaptations
(optional)
Agenda
Introduction

Migrate for Compute Engine concepts and requirements

Migrate for Compute Engine installation

Basic migration operations with Migrate for Compute Engine

Automating migrations with Migrate for Compute Engine

Application and special case migrations

Summary and next steps

Migrate for Compute Engine migration
workflow – review
Migrate Prepare to
Model Test Run-in-cloud
storage detach Detach

Determine VM Run application Move VM to the Detach from

Continue production
relationships and clones in the cloud, cloud, operational in Write data from Migrate for
operations while data
dependencies in without affecting minutes, while data cache to native Compute Engine
transfers in the
the automation production data or is accessed from GCP disks and run natively in
background
runbook uptime cache the cloud

Run on Prem
/ Cancel

Optional “safety
net” that allows
reverting to an
on-prem VM
Migrations happen in sprints and waves
Migrate
Prepare Execute move of
Build target
apps and
environments and
services to GCP
select migration
candidates from
backlog

Migration
Improve
Learn lessons,
Sprint
improve Test / Verify
Conduct UAT and
migration
regression testing
process

Optimize
Decouple state
and stateless,
scale horizontally,
rightsize & PVM
Improving the process

● Part of each sprint should be focused on…

○ Reviewing results
○ Reporting out successes
○ Refining and improving the process for the next sprint

● Consider a sprint review and a retrospective

Review Retrospective
Done/Not Done What went well Decide on what to improve

Problems/solutions Results (demo) Decide on how to improve

Backlog Priorities moving Assign improvement responsibilities

ahead
When you get back to work...

● You should create a test environment to further practice with Migrate for
Compute Engine (if you don't already have one)
● A guide for setting up your lab environment can be found at
http://bit.ly/velos-lab
 < Action Safe

Title Safe >