This guide shows you how to use the VM Migration Service, powered by CloudEndure, to import a server that is running a supported operating system from either an on-premises machine or a VM in another public cloud platform into Google Cloud Platform. At the end of this exercise, you will have a virtual machine instantiated in your project that is a replica of a machine in another environment.
- Launch the VM Migration Service from the Google Cloud Platform Console.
- Install the CloudEndure replication agent and copy the virtual machines into Compute Engine.
- Launch the newly created virtual machines.
The VM Migration Service is free to use. You will not be billed for this service either from Google or CloudEndure.
For VM instances you import into Compute Engine, you are billed according to the Compute Engine price sheet for VM instances.
Before you begin
To use the VM migration service, the source machines from which you are migrating must be running one of the following operating systems:
The following Windows operating systems are supported. Note that Windows Client operating systems and evaluation versions of Windows Server are not supported.
When migrating Windows operating systems to Compute Engine, a new on-demand SPLA license will be attached to Compute Engine VM instances. It is not possible to bring your own licenses to Compute Engine.
- Microsoft Windows Server 2016 64-bit, Standard and Datacenter editions
- Microsoft Windows Server 2012 R2 64-bit, Standard and Datacenter editions
Microsoft Windows Server 2012 64-bit, Standard and Datacenter editions
Microsoft Windows Server 2008 R2 64-bit, Standard and Datacenter editions
Microsoft Windows Server 2008 with Service Pack 2, 32-bit or 64-bit, Standard and Datacenter editions
Microsoft Windows Server 2003 with Service Pack 2, 32-bit or 64-bit, all editions
Microsoft Windows Server 2003 R2, with Service Pack 2, 32-bit or 64-bit, all editions
If you are migrating a Windows Server 2003 environment, your instances are billed at the rate for Windows Server VMs.
Before you migrate a Windows Server environment to Google Cloud Platform, you must prepare your Windows Server machine for the migration.
- SUSE Linux (SLES) 11 or above
- Debian Linux 8
- Kali Linux 2.0
- Ubuntu 12.04 or above
Red Hat Enterprise Linux (RHEL) 5.0 or above
CentOS 6.0 or above
Oracle Linux 6.0 or above
For SUSE, RHEL, and Oracle Linux, you must have an existing license to use the operating system. It is your responsibility to determine if you are properly licensed to run the OS. For Windows, any existing license will be converted to Google Cloud Platform's pay-as-you-go licensing.
Create a service account and service account key
In the GCP Console, go to the Service Accounts page.
If prompted, select a project.
Click Create Service Account.
Choose a name for the service account and grant the service account the Project Owner role.
Check the box next to Furnish a new private key and select JSON from the Key type list.
Click Create to create the service account and follow instructions to download the key.
Start the VM migration service
The VM migration service is offered by CloudEndure, a third-party partner of Google Cloud Platform. Before you can migrate your VM, you must sign up for CloudEndure. CloudEndure does not charge for this service.
In the GCP Console, open the VM Instances page.
To start the migration service, click Import VM.
Click Continue to go activate the migration service.
Activate the VM migration service
- On the CloudEndure Sign In page, click Sign up to sign up for the service.
On the Activation page, fill in the required details.
If you accept the terms of service, select the I agree to the CloudEndure Terms and Conditions box, and click Activate My Account to complete your registration. CloudEndure sends a confirmation email to the email address you used to register.
To activate your account, click the link the in the email.
You are redirected to the VM Migration Console. You can also access the console directly at any time.
Migrating your instance
You can use the VM Migration service to migrate your running Windows/Linux servers (physical/virtual/cloud-based) into a target cloud region of your choice, without any system disruption on your source infrastructure. The replication is continuous, and is done at the block level.
Below is a network diagram showing the networking and port requirements for the migration, followed by guidelines and some best practices for migrating your workload.
Prepare the staging network in the target region
In the target region, create a VPC network. This
network is used as a staging network to host the CloudEndure replication
servers. If you plan to use the
default network, you can skip this step.
Configure your CloudEndure account
- Log in to your activated CloudEndure account.
- Provide your project ID and the JSON key for the service account that you created earlier.
Select replication options
Select the target region where you want to migrate your VMs. Then,
choose the replication server network you created. If you didn't create
a new network, select the
Install the migration agent
Install the VM migration agent on each of the source machines that you want to migrate. The VM migration agent is required to copy the machine at the block level from the source to the destination. The agent can be installed on any supported operating system. This step copies data into Google Cloud Platform but does not launch your final target machines.
To install the migration agent, download the agent to the machines you want to migrate using the following instructions.
In the VM Migration console, click Help, then click How to add machines. The help page includes an installation token, which you need to install the migration agent. Copy the installation token.
On Linux, download the installer with the following command:
wget -O ./installer_linux.py https://gcp.cloudendure.com/installer_linux.py
Then run the installer using the following command. Replace [TOKEN] with your installation token:
sudo python ./installer_linux.py -t [TOKEN]
The Linux installer will require Python 2.4 or greater installed on the machine. Other Python versions won't be able to run the installer.
In a command prompt window, run the installer using the following command. Replace [TOKEN] with your installation token:
installer_win.exe -t [TOKEN]
After the agent installation completes successfully, you can track the progress of the migration in the VM Migration Console, in the Migration tab.
The progress of the data copy into Google Cloud Platform is shown under the Data Replication Progress column in the console.
If the Status column shows a red stop sign icon, verify the following:
The source server (with the installed agent) can communicate with VM Migration management server (
console.cloudendure.com) over TCP port 443. Linux servers may require access to repositories during installation.
The replication servers in the target region in the staging area (replication server network) can communicate with the VM Migration Service management server (
console.cloudendure.com) over TCP port 443 and outbound Internet connectivity over TCP port 443 for downloading installation packages. By default, CloudEndure’s service automatically adds a firewall rule to allow this access to the project.
The source server (with the installed agent) can communicate with the replication servers in the target region's replication server network over TCP port 1500. This firewall rule is also added by CloudEndure.
Configure the target machine
Next, for each VM instance that you are migrating, review the virtual machine properties by clicking on that server in the VM Migration Console, which opens the Blueprint tab.
The Blueprint tab lets you set the properties of your target VM instance. For example, you can change the target network the VM is created in, or the internal IP, and so on. You can change these properties at any time after the agent is installed. You don't have to wait for replication to complete to modify these settings. These properties include:
The target instance's machine type
The target instance's machine name
The target VPC network/subnet
The internal IP
The type of each persistent disk used by the VM instance
To save your changes, click Save Blueprint.
Verify initial sync completion
Depending on the size of the source disk, and the zone that you are migrating
your machine to, it might take several hours or more for the replication server
to sync your data. When the initial sync is complete, in the Data Replication
Progress column, the replicated machines show
Continuous Data Protection ,
indicating that you can test the creation of your target instances. In the
Status column, a purple launch icon is shown,
indicating you can start the target machine in the target location.
Test the creation of target VM instances
When you are ready to test the creation of the servers in the target location, select the server, then click Launch Target Machine, and click Test.
You can follow the progress of the target machine launch process in the Job Progress tab, which will also show if any errors were experienced during this process.
Test the availability of the target VMs
Go to the VM instances page and verify target VMs that were created. By default, the target VMs are prefixed with their original names. If you changed the name of the target instance in the blueprint, the target VM uses the name you chose.
Verify that you can log into the target machines. For Windows target machines, use RDP, and for Linux machines, use SSH.
Use the source machine’s credentials for logging into its target machine. Please use external SSH and RDP clients rather than trying to connect through the web interface of the Cloud Platform Console.
Test your applications on the target VMs
After creating test target VMs, you should test all your applications to see if they work correctly.
If anything needs to be adjusted, make adjustments in the Blueprint tab or on the source machine. Repeat this testing process until your applications work as expected.
Finalize your migrated instance
After testing your machines, you are ready to cut over to your instance on Google Cloud Platform.
- Plan for a short window of downtime. You can estimate the downtime based on your experience during the testing phase). During the window, you create the latest target test machines and confirm that the target workload works correctly.
- Stop or disable access to your source server in order to prevent user access and potential last minute changes that may not replicate to the target VMs.
- After you are certain that no changes can be made to your source servers, select the servers on the VM Migration Console and click Cutover to launch a final copy of the target VMs most up-to-date application state.
Once the target machines have been successfully created, repeat your sanity tests to ensure everything works as expected, and then configure your DNS servers to point all users to the new target machines.
Install guest environment packages
If you are experiencing problems logging into the VM instance, you might need to install the Compute Engine guest packages on the instance. The guest packages will set up things like user accounts, the instance hostname, support for shutdown and startup scripts, and so on.
To install the guest agent:
- For Linux instances, see Linux Guest Environment for Compute Engine.
For Windows instances, see Windows Guest Environment for Compute Engine.
Remove the CloudEndure agent from source servers
When you are certain that the live migrated machines in the target region are now in use, and you no longer need to create additional target machines, remove the CloudEndure agent from the source servers:
- In the VM Migration Console, check the boxes next to the machines you want to remove the migration agent from.
- Click Machine Actions, and select Remove machines from this console.
This stops the continuous replication and uninstalls the VM Migration agent from the source machine.
My service account was deleted and the VM migration service cannot move forward in the replication process.
If you changed the permissions of the service account or otherwise modified the account, reconfigure your account according to the steps to create a new account.
Limitations for Windows Server 2003 instances
Before migrating a Windows Server 2003 environment to Google Cloud Platform, be aware of the following limitations:
- You must not assign an external IP address to your Windows Server 2003 instance. Because support for Windows Server 2003 has ended, your instance might be vulnerable to security exploits. Use a VPC network to set up a private IP address for your instances.
- After you have migrated your Windows Server 2003 VMs, your copies of Windows are not automatically activated. You must activate Windows on each instance using a Multiple Activation Key (MAK), which is part of your volume licensing agreement with Microsoft.
- Support for Windows Server 2003 on Google Cloud Platform is limited. Because Microsoft no longer supports Windows Server 2003, you might run into issues that cannot be fully resolved.
The following features of Compute Engine are not available for Windows Server 2003 instances:
- Windows Server 2003 does not support the Volume Shadow Copy Service (VSS) for disk snapshots. If you want to take a snapshot of your disks, you must use the standard snapshot system.
- Your instance cannot have multiple network interfaces.
- Your cannot add GPUs or TensorFlow processing units (TPUs) to your instance.
Depending on your edition of Windows Server 2003, hardware support might be limited. During the migration process, you must select a machine type that is supported for your edition of Windows Server 2003.
For example, Windows Server 2003 Standard Edition supports a maximum of 4 vCPUs, and 32 GB of memory. During the migration, you must choose a machine type that has a maximum of 4 vCPUs and 32 GB of memory.
The Windows Guest Environment for Compute Engine, which transfers information between Compute Engine and your VM, supports the following limited set of features:
- You can create new user accounts on the migrated instance from the Console,
gcloudcommand-line tool, or the API.
- You can reset the password for user accounts that are already on the instance.
- You can create new user accounts on the migrated instance from the Console,
Stackdriver Windows monitoring and logging agents are not currently supported for Windows Server 2003 instances.