This document describes how to move a virtual machine (VM) instance between zones or regions.
Before you begin
- Read the zones documentation.
-
If you haven't already, then set up authentication.
Authentication is
the process by which your identity is verified for access to Google Cloud services and APIs.
To run code or samples from a local development environment, you can authenticate to
Compute Engine by selecting one of the following options:
Select the tab for how you plan to use the samples on this page:
gcloud
-
Install the Google Cloud CLI, then initialize it by running the following command:
gcloud init
- Set a default region and zone.
Go
To use the Go samples on this page in a local development environment, install and initialize the gcloud CLI, and then set up Application Default Credentials with your user credentials.
- Install the Google Cloud CLI.
-
To initialize the gcloud CLI, run the following command:
gcloud init
-
If you're using a local shell, then create local authentication credentials for your user account:
gcloud auth application-default login
You don't need to do this if you're using Cloud Shell.
For more information, see Set up authentication for a local development environment.
Java
To use the Java samples on this page in a local development environment, install and initialize the gcloud CLI, and then set up Application Default Credentials with your user credentials.
- Install the Google Cloud CLI.
-
To initialize the gcloud CLI, run the following command:
gcloud init
-
If you're using a local shell, then create local authentication credentials for your user account:
gcloud auth application-default login
You don't need to do this if you're using Cloud Shell.
For more information, see Set up authentication for a local development environment.
Node.js
To use the Node.js samples on this page in a local development environment, install and initialize the gcloud CLI, and then set up Application Default Credentials with your user credentials.
- Install the Google Cloud CLI.
-
To initialize the gcloud CLI, run the following command:
gcloud init
-
If you're using a local shell, then create local authentication credentials for your user account:
gcloud auth application-default login
You don't need to do this if you're using Cloud Shell.
For more information, see Set up authentication for a local development environment.
Python
To use the Python samples on this page in a local development environment, install and initialize the gcloud CLI, and then set up Application Default Credentials with your user credentials.
- Install the Google Cloud CLI.
-
To initialize the gcloud CLI, run the following command:
gcloud init
-
If you're using a local shell, then create local authentication credentials for your user account:
gcloud auth application-default login
You don't need to do this if you're using Cloud Shell.
For more information, see Set up authentication for a local development environment.
-
Requirements
This section lists requirements for moving a VM between zones and regions:
Project quota. Your project must have enough quota to do the following:
- Create new snapshots.
- Promote any ephemeral external IP addresses.
Create new VMs and disks in your destination region.
For example, if you have three disks attached to the VM you want to move, you need enough quota to create three temporary persistent disk snapshots and three new disks. After you create your new disks, you can delete your temporary snapshots.
Check the Quotas page to ensure that you have enough quota for the preceding resources. For more information, see Understanding quotas.
Persistent disks. The persistent disks attached to the VM that you want to move are not attached to other VMs.
Local SSDs. Local SSDs are meant for temporary storage, and data on local SSDs is not preserved through manual VM terminations. If you need to preserve local SSD data, replicate it by using a durable storage option like persistent disks.
GPUs. If your VM includes GPUs, verify that the GPUs you want to use are available in the VM's destination zone. For a list of GPUs and the zones that they are available in, see GPUs on Compute Engine.
Subnetwork. If you want to move your VM between regions, such as between
us-west1-a
andasia-south1-b
, and your VM belongs to a subnetwork, you must select a new subnetwork for your VM. For instructions on how to create subnets, see Adding subnets.
Limitation
If you move a VM across regions, you cannot preserve the VM's ephemeral internal or external IP address. You must choose a new IP address when you recreate the VM.
Resource properties
To move your VM, you must shut down the VM, move it to the destination zone or region, and then restart it. After you move your VM, update any references that you have to the original resource, such as any target VMs or target pools that point to the earlier VM.
During the move, some server-generated properties of your VM and disks change.
Properties that change for VMs
The following table describes properties that change for VMs:
Property name | Changes |
---|---|
Internal IP address | A new internal IP address is usually assigned, but the VM might keep the original internal IP address. |
External IP address | If the VM is moving between zones in the same region, the external IP address remains the same. Otherwise, pick a different external IP address for the VM instance. |
CPU platform | Depending on the available CPU platform in your destination zone, your VM might have a different CPU platform after it has been moved. For a full list of CPU platforms in each zone, see Available regions and zones. |
Network/subnetwork | If your VM belongs to a subnetwork and you are moving a VM across regions, you must pick a new subnetwork for your VM. VMs moving across zones in the same region retain the same subnetwork. |
Properties that change for disks
The following table describes properties that change for disks:
Property name | Changes |
---|---|
Source snapshot | The source snapshot of the new disk is set to the temporary snapshot that is created during the move. |
Source snapshot ID | The source snapshot ID is set to the temporary snapshot's ID. |
Source image | The source image field is empty. |
Image ID | The image ID is empty. |
Last detached timestamp | The last detached timestamp is empty. |
Last attached timestamp | The last attached timestamp changes to the timestamp when the new disk was attached to the new instance. |
Properties changing for both VMs and disks
The following table describes properties that change for both VMs and disks:
Property name | Changes |
---|---|
ID | A new resource ID is generated. |
Creation timestamp | A new creation timestamp is generated. |
Zone resource URLs | All zone resource URLs change to reflect the destination zone. The
following list shows the resource URLs that change:
|
Move a VM across zones or regions
To move a VM across zones or regions, you can do the following:
- Create a machine image of your source VM.
- Create a VM from the machine image in a different zone or region.
The following examples show how to move a VM across zones.
gcloud
In this example, you move a VM named myinstance
that has two persistent disks
named mybootdisk
and mydatadisk
, from europe-west1-c
to us-west1-b
.
Identify the disks that are associated with the VM that you want to move:
gcloud compute instances describe myinstance --format="list(name,status,disks)"
In this example, you find the following two associated disks for the
myinstance
VM:- A boot disk called
mybootdisk
- A data disk called
mydatadisk
- A boot disk called
Set the auto-delete state of
mybootdisk
andmydatadisk
tofalse
to ensure that the disks are not automatically deleted when the VM is deleted.gcloud compute instances set-disk-auto-delete myinstance --zone europe-west1-c \ --disk mybootdisk --no-auto-delete
If the state was updated,
gcloud compute
returns the responseUpdated [...]
. If the auto-delete state was already set to false, thengcloud compute
returns:No change requested; skipping update for [myinstance].
(Optional) Save your VM metadata.
When you delete your VM, the VM metadata is also removed. You can save that information in a separate file, then reapply the VM metadata to the new VM.
Describe your VM's metadata like so:
gcloud compute instances describe myinstance --zone europe-west1-c
Save the contents to a separate file.
Create backups of your data by using persistent disk snapshots.
As a precaution, create backups of your data while the persistent disks are still attached to the VM by using persistent disk snapshots. Before you take a snapshot, ensure that it is consistent with the state of the persistent disk by adhering to snapshot best practices.
After you clear your disk buffers, create the snapshots:
gcloud compute disks snapshot mybootdisk mydatadisk \ --snapshot-names backup-mybootsnapshot,backup-mydatasnapshot \ --zone europe-west1-c
To verify that the snapshot is created, run
gcloud compute snapshots list
.(Optional) If you're moving a VM across zones within the same region, and you want to preserve its ephemeral internal or external IP address, promote the internal or external IP address to a static IP address, which you can reuse later.
Delete your VM.
Deleting your VM shuts it down cleanly and detach any persistent disks.
gcloud compute instances delete myinstance --zone europe-west1-c
gcloud
prompts you to confirm the deletion:The following VMs are deleted. Any attached disks configured to be auto-deleted are deleted unless they are attached to any other VMs or the `--keep-disks` flag is given and specifies them for keeping. Deleting a disk is irreversible and any data on the disk is lost. — [myinstance] in [europe-west1-c]
Do you want to continue (Y/n)?
Because you turned off the auto-delete state for the disks earlier in this process, enter Y to continue and ignore the warning.
Next, create another snapshot of both the boot disk and the data disk.
gcloud compute disks snapshot mybootdisk mydatadisk \ --snapshot-names mybootsnapshot,mydatasnapshot \ --zone europe-west1-c
Created [.../mydatasnapshot]. Created [.../mybootsnapshot].
(Optional) Delete your persistent disks.
If you plan to reuse the names of the persistent disks for the new disks, you must delete the existing disks to release the names. Deleting your disks also saves on persistent disk storage costs.
If you do not plan to reuse the same disk names, you don't need to delete them.
gcloud compute disks delete mybootdisk mydatadisk --zone europe-west1-c
Create new persistent disks in
us-west1-b
from the snapshots you created. First create the boot disk.gcloud compute disks create mybootdiskb --source-snapshot mybootsnapshot \ --zone us-west1-b
Created [.../mybootdiskb]. NAME ZONE SIZE_GB TYPE STATUS mybootdiskb us-west1-b 100 pd-standard READY
Then create the data disk.
gcloud compute disks create mydatadiskb --source-snapshot mydatasnapshot \ --zone us-west1-b
Created [.../mydatadiskb]. NAME ZONE SIZE_GB TYPE STATUS mydatadiskb us-west1-b 4000 pd-standard READY
Recreate your VM in
us-west1-b
.If you had opted to save your VM metadata in a file, for example
myinstance.describe
, you can use it to set the same metadata on your VM.If your VM had a static external IP address, you can reassign that address to your new VM by specifying the
--address [ADDRESS]
option. If you are moving a VM across regions, you must pick a different external IP address for the new VM instance.If your VM had a static internal IP address, you can reassign that address to your new VM by specifying the
--private-network-ip ADDRESS
option. If you are moving a VM across regions, you must pick a different internal IP address for the new VM instance.If your VM included GPUs, add GPUs to the VM using the
--accelerator
option.If the VM uses a specific subnet, add the
--subnet [SUBNET_NAME]
flag.
For a complete list of additional flags, see gcloud compute instances create.
gcloud compute instances create myinstanceb --machine-type n1-standard-4 \ --zone us-west1-b \ --disk name=mybootdiskb,boot=yes,mode=rw \ --disk name=mydatadiskb,mode=rw
Created [.../myinstanceb]. NAME ZONE MACHINE_TYPE INTERNAL_IP EXTERNAL_IP STATUS myinstanceb us-west1-b n1-standard-4 10.240.173.229 146.148.112.106 RUNNING
(Optional) Delete your persistent disk snapshots.
After you confirm that your virtual machines are moved, save on storage costs by deleting the temporary snapshots that you created.
gcloud compute snapshots delete mybootsnapshot mydatasnapshot
If you no longer need your backup snapshots, delete those snapshots as well:
gcloud compute snapshots delete backup-mybootsnapshot backup-mydatasnapshot
Go
Get the details of the VM and identify the disks that are attached to the VM.
Set the auto-delete state of the boot disk and data disk to
false
to ensure that the disks are not automatically deleted when the VM is deleted.Create backups of your data by using persistent disk snapshots.
As a precaution, create backups of your data while the persistent disks are still attached to the VM by using persistent disk snapshots. Before you take a snapshot, ensure that it is consistent with the state of the persistent disk by adhering to snapshot best practices.
After you clear your disk buffers, create the snapshots:
Delete your VM from the source zone.
Next, create another snapshot of both the boot disk and the data disks.
(Optional) Delete your persistent disks.
If you plan to reuse the names of the persistent disks for the new disks, you must delete the existing disks to release the names. Deleting your disks also saves on persistent disk storage costs.
If you do not plan to reuse the same disk names, you don't need to delete them.
Create new persistent disks in the destination zone from the snapshots you created. First create the boot disk, and then the data disks.
Recreate your VM with the new disks in the destination zone.
(Optional) Delete the temporary disk snapshots. After you confirm that your virtual machines are moved, save on storage costs by deleting the temporary snapshots that you created.
Java
Get the details of the VM and identify the disks that are attached to the VM.
Set the auto-delete state of the boot disk and data disk to
false
to ensure that the disks are not automatically deleted when the VM is deleted.Create backups of your data by using persistent disk snapshots.
As a precaution, create backups of your data while the persistent disks are still attached to the VM by using persistent disk snapshots. Before you take a snapshot, ensure that it is consistent with the state of the persistent disk by adhering to snapshot best practices.
After you clear your disk buffers, create the snapshots:
Delete your VM from the source zone.
Next, create another snapshot of both the boot disk and the data disks.
(Optional) Delete your persistent disks.
If you plan to reuse the names of the persistent disks for the new disks, you must delete the existing disks to release the names. Deleting your disks also saves on persistent disk storage costs.
If you do not plan to reuse the same disk names, you don't need to delete them.
Create new persistent disks in the destination zone from the snapshots you created. First create the boot disk, and then the data disks.
Recreate your VM with the new disks in the destination zone.
(Optional) Delete the temporary disk snapshots. After you confirm that your virtual machines are moved, save on storage costs by deleting the temporary snapshots that you created.
Node.js
Get the details of the VM and identify the disks that are attached to the VM.
Set the auto-delete state of the boot disk and data disk to
false
to ensure that the disks are not automatically deleted when the VM is deleted.Create backups of your data by using persistent disk snapshots.
As a precaution, create backups of your data while the persistent disks are still attached to the VM by using persistent disk snapshots. Before you take a snapshot, ensure that it is consistent with the state of the persistent disk by adhering to snapshot best practices.
After you clear your disk buffers, create the snapshots:
Delete your VM from the source zone.
Next, create another snapshot of both the boot disk and the data disks.
(Optional) Delete your persistent disks.
If you plan to reuse the names of the persistent disks for the new disks, you must delete the existing disks to release the names. Deleting your disks also saves on persistent disk storage costs.
If you do not plan to reuse the same disk names, you don't need to delete them.
Create new persistent disks in the destination zone from the snapshots you created. First create the boot disk, and then the data disks.
Recreate your VM with the new disks in the destination zone.
(Optional) Delete the temporary disk snapshots. After you confirm that your virtual machines are moved, save on storage costs by deleting the temporary snapshots that you created.
Python
Get the details of the VM and identify the disks that are attached to the VM.
Set the auto-delete state of the boot disk and data disk to
false
to ensure that the disks are not automatically deleted when the VM is deleted.Create backups of your data by using persistent disk snapshots.
As a precaution, create backups of your data while the persistent disks are still attached to the VM by using persistent disk snapshots. Before you take a snapshot, ensure that it is consistent with the state of the persistent disk by adhering to snapshot best practices.
After you clear your disk buffers, create the snapshots:
Delete your VM from the source zone.
Next, create another snapshot of both the boot disk and the data disks.
(Optional) Delete your persistent disks.
If you plan to reuse the names of the persistent disks for the new disks, you must delete the existing disks to release the names. Deleting your disks also saves on persistent disk storage costs.
If you do not plan to reuse the same disk names, you don't need to delete them.
Create new persistent disks in the destination zone from the snapshots you created. First create the boot disk, and then the data disks.
Recreate your VM with the new disks in the destination zone.
(Optional) Delete the temporary disk snapshots. After you confirm that your virtual machines are moved, save on storage costs by deleting the temporary snapshots that you created.
What's next
- Learn how to change the default zone/region for your project.
- Learn about live migration.
- Check a VM's status.
- Learn about migrating VMs to Compute Engine.