Move your workload to a new compute instance

In certain situations, you might want to move your workload from an existing virtual machine instance (VM) to a newer VM. Reasons to move to a new VM include the following:

  • Take advantage of the new VM types for faster storage or networking speeds. For example, upgrading from C2 to H3 for improved networking bandwidth.
  • Benefit from greater price performance relative to the source VM type. For example, upgrading from N1 to N4 for greater value on the 5th Generation Intel Xeon processor.
  • Use features only available on the new VM type. For example, migrating from C3 to N4 to take advantage of additional VM shapes offered by custom machine types.
  • Change a virtual machine (VM) instance to a bare metal instance.

When upgrading to the newest 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 Edit the machine type of a compute instance if the following conditions are met by the current VM:

  • The operation system (OS) is supported by the new machine series
  • The current VM is using only features or disk types that are supported by the new machine series
  • The VM doesn't use Local SSD storage
  • The VM isn't part of a managed instance group (MIG)

Evaluate VM migration options

Migrating from one VM type to another is dependent upon several factors, including: regional availability of the new VM type, compatibility of the source and destination disk types, Local SSD availability, disk interface, storage options and network interfaces with respect to the guest OS and compatible VMs.

Compute requirements

  • Explore the machine family resource documentation to identify what VM types are suitable for your workload. Consider whether your application requires specific hardware (GPUs), high performance, or lower costs.
  • Review the features of the disk types supported by the new VM. Not all features available with Persistent Disk are supported by Hyperdisk. For example, being able to attach the same disk to multiple VMs is only available for Persistent Disk, not Hyperdisk.
  • Review the features for the new VM type. The new VM machine series might not support the same features that you use with your current VM, such as custom machine types, Local SSD, or Shielded VM.
  • Review the regions and zones to ensure the new machine series is available in all the regions as your current VM. You might need to adjust your deployment, availability, and disaster recovery plans.
  • Review your OS migration plan to move from SCSI to NVMe.
    • If the new VM requires a newer version of the OS, verify that your applications are compatible with the newer OS.
    • If you're 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.

Storage requirements

  • Review the supported storage types and the supported storage interfaces for the new VM machine series.
    • By default, first and second generation VMs use only the Persistent Disk storage type and the VirtIO-SCSI interfaces.
    • Third generation and newer machines series (like M3, C3, and N4) support only the NVMe interface, and only support Hyperdisk and Local SSD storage types.
  • Make sure your applications and guest operating system (OS) support the disk interface type used by the new VM.
  • If your current VM uses a boot disk or data disk type that is not supported for the new VM series, for example pd-standard, you can use a snapshot to change the source disk to a new disk type, as described in Change the disk type.

Networking requirements

  • Review the supported networking interfaces for the new VM. Newer VM series like M3, C3, and N4 support only gVNIC interfaces and don't support VirtIO-net interfaces. Make sure your application supports the interfaces available in the new VM type.

Use the gcloud compute instances describe command to view the VM's nic-type, which must be set to gVNIC:

  gcloud compute instances describe VM_NAME --zone=ZONE

Prepare to move your existing VMs

After you've completed the evaluation section, the next step is to prepare to move your VMs by making changes to the source VM.

Prepare compute resources

  1. Request quota in the region and zones where you plan to move your resources. If you have existing quota for a machine type, you can request to move that quota. The process takes a few days to complete.
  2. Create a reservation for the new VM to ensure the machine resources are available in the new region and zones.
  3. If you're creating a VM in a new region, create a VPC network and subnets in the new region.
  4. Perform an in-place upgrade of your OS to a version that is supported by the new VM and verify that it's working as expected. If the new VM supports the current version of your OS, no additional work is needed.
  5. 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.

Prepare storage resources

  1. 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 a VM instance or Create and start an Arm VM instance and configure the new VM according to your specifications.
  2. If your current VM has a Persistent Disk boot disk, and the new VM only supports Hyperdisk, you must migrate the Persistent Disk volume to a Hyperdisk. See Change the disk type to replace the boot disk of an instance, see Detach and reattach a boot disk.
  3. If your new VM doesn't support the same disk types as your current VM, you might need to update your deployment scripts or instance templates.
  4. Make sure that your applications don't reference the attached Persistent Disks using their device names on Linux systems.
  5. If you need to move Local SSD information, create a blank disk large enough to backup your Local SSD disks.
    • If possible, use a disk type that is supported by the new VM.
    • If there are no disk types that are supported by both the current VM and the new VM, then create the temporary disk using a Persistent Disk type supported by the current VM.
  6. Attach the disk to the current VM, then format and mount the disk. Copy the data from the Local SSD disks attached to the current VM to this temporary disk.
  7. Create snapshots of all the disks attached to the current VM. Data stored on the disk after a snapshot is taken is not on the temporary disk, be sure to capture all data in your snapshots.
    • Application consistent snapshots
    • Standard snapshots
    • Include the temporary disk that holds the Local SSD data
  8. 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, Hyperdisk Balanced, or Hyperdisk Extreme.
    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, Hyperdisk Balanced, or Hyperdisk Extreme.
  9. Move non-boot Persistent Disk from the old VM to the new VM.
    • You can create a snapshot of your Persistent Disk, add a new Hyperdisk of the same or larger size to the new VM, and restore the snapshot to the Hyperdisk.
    • You can alternatively transfer files from one VM to the other.
  10. Optional: If you moved the contents of Local SSD disk to a supported disk type at the start of the migration, you can now move the data saved to a Local SSD and remove the temporary disk.
  11. To prepare to use the NVMe interface and drivers for Local SSD, see Choosing an interface.

If you're migrating from a VM that runs Linux, test that any applications or scripts modified to use symlinks instead of device names work correctly.

If you're migrating from a VM that runs Microsoft Windows:

  • You must update 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.
  • Windows must be reconfigured to start using the Microsoft NVMe driver (StorNVMe). This can be done by either of the following two methods:
    • Rename the VM, then verify that the VM boots correctly. Renaming the VM changes the UUID during migration.
    • Use metadata to force Windows to load SCSI and NVMe drivers. See the Known issues document for details. This defines a startup script, which forces Windows to load drivers that might have otherwise been skipped.

Prepare network resources

Move your workload to the new VM

After preparing your VMs for migration, the next step is to move your workload to the new VM.

If you are moving your VMs from the first generation to the second, read the instructions on the Edit the machine type of a VM page. If you want to change the name of your existing VM, review the information at Rename a VM.

Permissions required for this task

To perform this task, you must have the following permissions:

  • compute.instances.setMachineType on the VM

This section describes how to move your workload from a first or second generation VM to a third (or newer) generation VM. During this procedure, you create a new VM instance, then move your workloads to the new VM.

Create the new VM

When moving your workloads from first or second generation VMs (N1 or N2 for example), you must first create a new VM and then move your workloads.

  1. Stop your existing VM before making any changes to your resources.
  2. Select the machine type that supports your backed up storage resources.
  3. Select a supported OS image, or use a custom image you created.
  4. Select a supported boot disk.
  5. Specify the new VPC network, if you're creating the VM in a different region.
  6. Specify the static IP addresses, if you promoted the ephemeral IP addresses of the old VM.
  7. Add the disks you detached from the old VM to the new VM.
  8. If the disks attached to the old VM use a disk type that is not supported by the new VM, then add blank disks. When creating a new VM using a supported disk type and specify a size that is at least as large as the old disks. This includes any temporary disks you attached to the old to hold a copy of the Local SSD data.
  9. Reassign any static IP addresses associated with the original VM to the new VM.
  10. Configure the necessary users, drivers, packages, and file directories on the new VM to support your workload.
  11. Install your modified applications and programs on the new VM. Recompile the programs on the new operating system or architecture, if required.

After the instance starts

  1. If you added blank disks to the new VM, then format and mount those disks. Then restore snapshots taken of the old disks to the new disks.
  2. Copy data from the temporary disk back to the Local SSD disks, and then delete the temporary disk.
  3. If you're not using a custom image, then install the app software and any required drivers or packages.
  4. Update the forwarding rules.
  5. Update the DNS entries, if needed.
  6. After verifying the new VM is working as intended, and all data has been copied over, delete the old VM, if you didn't remove it earlier.
  7. Create scheduled snapshots for the new disks.

If you encounter issues when moving your workload, contact your Technical Account Manager (TAM) or the Google Professional Services Organization (PSO) for assistance.

What's next