In certain situations, you need to move your workload from an existing virtual machine instance (VM) to a new VM. Reasons to move to a new VM include the following:
- Upgrading the operating system to a new release
- Switching from the x86 architecture to the Arm architecture
- Upgrading to the latest generation VM machine series
In these cases, you might have to create a new VM and move your workload to the new VM.
When upgrading to the latest generation VM machine series, if the operating system on your current VM is supported by the new generation, and your current VM is not using any features or disk types that are not supported with the new machine series, then you might be able to use the simpler procedure described in Move your VM to a new machine series.
Prepare to move to a new VM
You can move your current VM to a new VM—for example, from
n2d-standard-32
to t2a-standard-32
or from m1-ultramem-160
to
m3-ultramem-128
. Review and resolve the following items before starting the
migration.
- Review the available regions and zones for the new VM machine series. The new machine series might not be available in all the regions as your current VM. Adjust your deployment, availability, and disaster recovery plans as needed.
- Check that the operating system version for your current VM is supported for
the new VM machine series. For more information, see
operating system details.
- If the new VM requires a newer version of the operating system, verify that your applications are compatible with the newer OS version.
- If moving to Arm and an Arm image is not available for your current operating system, choose a new operating system to run your applications on and verify that your applications are compatible with the new operating system.
- Review the machine series documentation to see what features are available for the new VM. The new VM machine series might not support the same features that you use with your current VM, such as custom machine types or Shielded VM.
- Review the supported interfaces for the new VM machine series. Newer VM
series such as T2A and third generation VMs (like M3 or C3) support only
gVNIC and NVMe interfaces. Make sure your applications support those
interfaces.
- If migrating from a VM that uses the SCSI disk interface to a VM that
supports only the NVMe disk interface, make sure that your applications
and scripts don't refer to the attached disks by device name, such as
sda1
. Instead, use the symlink for the disks that appear in/dev/disk/by-id/
. - If migrating from a VM that runs Microsoft Windows, you must replace the NVME driver on VMs created before May 2022. This applies to the boot disk in your current VM and any previously created snapshots or custom images that are used to create a new VM.
- If migrating from a first or second generation VM where you used the
default (VirtIO) network interface to a third generation or T2A VM that
supports only the gVNIC network interface, you might need to
address the following issues:
- If you used a custom image to create your VM, the image must be tagged
to use gVNIC (the
guest-os-features
property must include the stringGVNIC
) and must include the gVNIC driver, as documented in Create a custom image that supports gVNIC. To check that your VM is tagged for gVNIC, use the instructions in the Diagnosis section of VM instance didn't boot. - If you configured custom NIC queue counts, see Queue allocations and changing the machine type.
- If you used a custom image to create your VM, the image must be tagged
to use gVNIC (the
- If migrating from a VM that uses the SCSI disk interface to a VM that
supports only the NVMe disk interface, make sure that your applications
and scripts don't refer to the attached disks by device name, such as
- Review the supported disk types for the new VM. Newer VM series such as M3
and C3 don't support the
pd-standard
Persistent Disk type. If your current VM uses a boot disk type that is not supported for the new VM series, you can use a snapshot to change the boot disk to a new disk type, as described in Move your workload to the new VM. - If your VM has attached Local SSD, and you want to move to a third generation VM, verify that Local SSD disks are supported for the new machine type.
- If the new VM uses a different architecture, verify that your applications
or programs can run on the new architecture, or determine if they require
modifications.
- If your application was written using the latest versions of a programming language, it's likely to be compatible with Arm without requiring further modification.
- To run interpreted languages like Python, Ruby, and JavaScript, you must install an Arm-compatible runtime environment on your Arm VM.
- Compiled x86 binaries cannot run on Arm, and compiled Arm
binaries cannot run on x86 platforms.
- You need to recompile your binaries for Arm, typically with no modification to your source code.
- You may also need to upgrade your packages and libraries to include the Arm equivalents for the versions that you used on x86 VMs.
Move your workload to the new VM
To move your workload to a new VM, you first create a new VM, then move your workload to the new VM.
- Complete the steps in Prepare to move to a new VM on this page.
- If your existing VM uses Local SSD disks that contain data that you want to keep, move the contents of those disks to a supported Persistent Disk type.
If your current VM uses
pd-standard
Persistent Disk for the boot disk, use the following steps to move to a VM that doesn't supportpd-standard
disks:- If you are migrating a very small number of VMs:
- Create a snapshot
of the
pd-standard
boot disk of your current VM. - Create a VM from the boot disk snapshot.
When creating the new VM, choose one of the supported disk types for
the boot disk, for example, PD-Balanced (
pd-balanced
) or PD-SSD (pd-ssd
).
- Create a snapshot
of the
- If you are migrating multiple VMs, use a custom image to create
the new VMs:
- Create a snapshot
of the
pd-standard
boot disk of your current VM. - Create a custom image using the disk snapshot as the source.
- Create a VM from the custom image.
When creating the new VM, choose one of the supported disk types for
the boot disk, for example, PD-Balanced (
pd-balanced
) or PD-SSD (pd-ssd
).
- Create a snapshot
of the
- If you are migrating a very small number of VMs:
If your current VM uses a boot disk type that is supported in the new VM machine series, follow the instructions at either Create and start an Arm VM instance or Create and start a VM instance and configure the new VM according to your specifications.
Configure the necessary users, drivers, packages, and file directories on the new VM to support your workload.
Move non-boot Persistent Disk from the old VM to the new VM.
- For disk types that are supported on the new VM machine series, you can do this by detaching the Persistent Disk from the old VM and adding it to the new VM.
- For disk types that aren't supported on the new VM machine series, you can create a snapshot of your disk, add a new disk of the same or larger size to the new VM, and restore the snapshot to the new disk.
- You can alternatively transfer files from one VM to the other, if you haven't deleted the original VM.
Install your modified applications and programs on the new VM. Recompile the programs on the new operating system or architecture, if required.
Reassign any static IP addresses associated with the original VM to the new VM.
Optional: Move the data saved to a Persistent Disk back to a local SSD.
If you encounter issues when moving your workload from an x86 VM to an Arm VM, contact your Technical Account Manager (TAM) or the Google Professional Services Organization (PSO) for assistance.
What's next
- Read the troubleshooting tips.
- Learn more about T2A machine series.
- Learn more about the migration process.