Move your workload to a new compute instance

In certain situations, you need to move your workload from an existing compute instance to a new compute instance. Reasons to move to a new compute instance 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 machine series
  • Changing a virtual machine (VM) instance to a bare metal instance

In these cases, you might have to create a new compute instance and move your workload to the new instance.

When upgrading to the latest generation machine series, if the operating system on your current compute instance is supported by the new machine series, and your current instance isn't 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 compute instance to a new machine series.

Prepare to move to a new compute instance

You can move your current compute instance to a new instance—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 machine series. The new machine series might not be available in all the regions as your current compute instance. Adjust your deployment, availability, and disaster recovery plans as needed.
  2. Check that the operating system (OS) version for your current compute instance is supported for the new machine series. For more information, see operating system details.
    • If the new machine series requires a newer version of the OS, 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 OS to run your applications on and verify that your applications are compatible with the new OS.
  3. Review the machine series documentation to see what features are available for the new machine series. The new machine series might not support the same features that you use with your current compute instance, such as custom machine types or Shielded VM.
  4. Review the supported interfaces for the new machine series. Newer machine series such as T2A and third generation or later machine series such as M3 or C3 support only gVNIC and NVMe interfaces. Make sure your applications support those interfaces.
    1. If migrating from a compute instance that uses the SCSI disk interface to a machine series 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 compute instance that uses Microsoft Windows, you must replace the NVME driver on VMs created before May 2022. This applies to the boot disk in your current instance and any previously created snapshots or custom images that are used to create a new compute instance.
    3. If migrating from a compute instance that uses a first or second generation machine series and the default (VirtIO) network interface to a T2A or third generation or later machine series that supports only the gVNIC network interface, you might need to address the following issues:
      • If you used a custom image to create your compute instance, then the image must be tagged to use gVNIC. This means the guest-os-features property must include the string GVNIC. Also, the custom image must include the gVNIC driver, as documented in Create a custom image that supports gVNIC. To check that the OS image of a compute instance is tagged for gVNIC, use the instructions in the Diagnosis section of VM instance didn't boot.
      • If you configured custom NIC queue counts for the compute instance, see Queue allocations and changing the machine type.
    4. If you are changing a VM instance to a bare metal instance, you might need to install your own hypervisor or virtual machine software on the bare metal instance. Bare metal instances use the IDPF network interface presented as only a physical function, not a virtual function.
  5. Review the supported disk types for the new machine series. Newer machine series such as M3 and C3 don't support the pd-standard Persistent Disk type. Some fourth generation machine series like N4 don't support any type of Persistent Disk. If your current compute instance uses a boot disk type that isn't supported for the new machine series, then you can use a snapshot to change the boot disk to a new disk type. This procedure is described in Move your workload to the new compute instance.
  6. If your compute instance uses Local SSD, and you want to move to a third generation or later machine series, verify that Local SSD disks are supported for the new machine type.
  7. If the new machine series 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 instance.
  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 compute instances.

Move your workload to the new compute instance

To move your workload to a new compute instance, you first create a new compute instance, then move your workload to the new compute instance.

  1. Complete the steps in Prepare to move to a new compute instance on this page.
  2. If your existing compute instance uses Local SSD disks that contain data that you want to keep, move the contents of those disks to a supported type of Persistent Disk or Hyperdisk.

  3. If your current virtual machine (VM) instance uses pd-standard Persistent Disk for the boot disk, use the following steps to move to a VM instance that doesn't support pd-standard disks:

    1. If you are migrating a very small number of VM instances:
      1. Create a snapshot of the pd-standard boot disk of your current VM instance.
      2. Create a VM from the boot disk snapshot. When creating the new VM instance, choose one of the supported disk types for the boot disk, for example, Balanced Persistent Disk (pd-balanced), SSD Persistent Disk (pd-ssd), or Hyperdisk Balanced (hyperdisk-balanced).
    2. If you are migrating multiple VM instances, use a custom image to create the new VM instances:
      1. Create a snapshot of the pd-standard boot disk of your current VM instance.
      2. Create a custom image using the disk snapshot as the source.
      3. Create a VM instance from the custom image. When creating the new VM instance, choose one of the supported disk types for the boot disk, for example, Balanced Persistent Disk (pd-balanced), SSD Persistent Disk (pd-ssd), or Hyperdisk Balanced (hyperdisk-balanced).

  4. If your current VM instance uses a boot disk type that is supported in the new machine series, then follow the instructions at either Create and start an Arm VM instance or Create and start a VM instance and configure the new VM instance according to your specifications.

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

  6. Move non-boot Persistent Disk and Google Cloud Hyperdisk from the old compute instance to the new compute instance.

    • For disk types that are supported by the new machine series, you can do this by detaching the Persistent Disk or Google Cloud Hyperdisk from the old compute instance and adding it to the new compute instance.
    • For disk types that aren't supported by the new machine series, you can create a snapshot of your disk, add a new disk of the same or larger size to the new compute instance, and restore the snapshot to the new disk.
    • You can alternatively transfer files from one compute instance to the other, if you haven't deleted the original compute instance.

  7. Install your modified applications and programs on the new compute instance. Recompile the programs on the new operating system or architecture, if required.

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

  9. Optional: Move the data saved to a Persistent Disk or Google Cloud Hyperdisk back to a Local SSD disk, if Local SSD are supported with the new machine series.

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