Move your workload from an existing VM to a new VM


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 third generation 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.

  1. 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.
  2. 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.
  3. 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.
  4. 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.
    1. 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/.
    2. 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.
    3. 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:
  5. 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.
  6. 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.
  7. 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.
  8. 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.

  1. Complete the steps in Prepare to move to a new VM on this page.
  2. 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.
  3. 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 support pd-standard disks:

    1. If you are migrating a very small number of VMs:
      1. Create a snapshot of the pd-standard boot disk of your current VM.
      2. 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).
    2. If you are migrating multiple VMs, use a custom image to create the new VMs:
      1. Create a snapshot of the pd-standard boot disk of your current VM.
      2. Create a custom image using the disk snapshot as the source.
      3. 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).
  4. 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.

  5. Configure the necessary users, drivers, packages, and file directories on the new VM to support your workload.

  6. 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.
  7. Install your modified applications and programs on the new VM. Recompile the programs on the new operating system or architecture, if required.

  8. Reassign any static IP addresses associated with the original VM to the new VM.

  9. 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