Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://cloud.google.com/compute/docs/instances/moving-instance-across-zones below:

Move a VM instance between zones or regions | Compute Engine Documentation

Stay organized with collections Save and categorize content based on your preferences.

Linux Windows

This document describes how to move a virtual machine (VM) instance between zones or regions.

• 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

  1. Install the Google Cloud CLI. After installation, initialize the Google Cloud CLI by running the following command:

     gcloud init

     If you're using an external identity provider (IdP), you must first sign in to the gcloud CLI with your federated identity.

     Note: If you installed the gcloud CLI previously, make sure you have the latest version by running gcloud components update.
  2. 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.

  If you're using an external identity provider (IdP), you must first sign in to the gcloud CLI with your federated identity.

  Note: If you installed the gcloud CLI previously, make sure you have the latest version by running gcloud components update.

  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.

  If an authentication error is returned, and you are using an external identity provider (IdP), confirm that you have signed in to the gcloud CLI with your federated identity.

  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.

  If you're using an external identity provider (IdP), you must first sign in to the gcloud CLI with your federated identity.

  Note: If you installed the gcloud CLI previously, make sure you have the latest version by running gcloud components update.

  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.

  If an authentication error is returned, and you are using an external identity provider (IdP), confirm that you have signed in to the gcloud CLI with your federated identity.

  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.

  If you're using an external identity provider (IdP), you must first sign in to the gcloud CLI with your federated identity.

  Note: If you installed the gcloud CLI previously, make sure you have the latest version by running gcloud components update.

  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.

  If an authentication error is returned, and you are using an external identity provider (IdP), confirm that you have signed in to the gcloud CLI with your federated identity.

  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.

  If you're using an external identity provider (IdP), you must first sign in to the gcloud CLI with your federated identity.

  Note: If you installed the gcloud CLI previously, make sure you have the latest version by running gcloud components update.

  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.

  If an authentication error is returned, and you are using an external identity provider (IdP), confirm that you have signed in to the gcloud CLI with your federated identity.

  For more information, see Set up authentication for a local development environment.

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 and asia-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.

  Note: The method of moving a VM described in this section also works for VMs in a TERMINATED state, or Shielded VM that use UEFI firmware.

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.

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.

The following table describes properties that change for VMs:

The following table describes properties that change for disks:

The following table describes properties that change for both VMs and disks:

• A VM's source disk URL
• A VM's machine type URL
• Self-link URLs
• Zone URLs
• Disk type URLs
• Any URLs of VMs listed in a disk's users[] list

To move a VM across zones or regions, you can do the following:

1. Create a machine image of your source VM.
2. Create a VM from the machine image in a different zone or region.

The following examples show how to move a VM across zones.

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.

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

2. Set the auto-delete state of mybootdisk and mydatadisk to false 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 response Updated [...]. If the auto-delete state was already set to false, then gcloud compute returns:

   No change requested; skipping update for [myinstance].

3. (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.

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

   Note: If you are running a Windows VM, the VM must be terminated before you can create a snapshot. Follow the steps to create a snapshot for Windows VM.

   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.

5. (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.

   Note: If you're moving your VM across regions, you cannot preserve an VM's ephemeral internal or external IP address . You must choose a new IP address when you recreate the VM.

6. Delete your VM.

   Note: If you already terminated your Windows VM in a previous step, skip this step.

   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.

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

8. (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

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

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

11. (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

1. Get the details of the VM and identify the disks that are attached to the VM.

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

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

   Note: If you are running a Windows VM, the VM must be terminated before you can create a snapshot. Follow the steps to create a snapshot for Windows VM.

   After you clear your disk buffers, create the snapshots:

4. Delete your VM from the source zone.

5. Next, create another snapshot of both the boot disk and the data disks.

6. (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.

7. Create new persistent disks in the destination zone from the snapshots you created. First create the boot disk, and then the data disks.

8. Recreate your VM with the new disks in the destination zone.

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

1. Get the details of the VM and identify the disks that are attached to the VM.

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

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

   Note: If you are running a Windows VM, the VM must be terminated before you can create a snapshot. Follow the steps to create a snapshot for Windows VM.

   After you clear your disk buffers, create the snapshots:

4. Delete your VM from the source zone.

5. Next, create another snapshot of both the boot disk and the data disks.

6. (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.

7. Create new persistent disks in the destination zone from the snapshots you created. First create the boot disk, and then the data disks.

8. Recreate your VM with the new disks in the destination zone.

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

1. Get the details of the VM and identify the disks that are attached to the VM.

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

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

   Note: If you are running a Windows VM, the VM must be terminated before you can create a snapshot. Follow the steps to create a snapshot for Windows VM.

   After you clear your disk buffers, create the snapshots:

4. Delete your VM from the source zone.

5. Next, create another snapshot of both the boot disk and the data disks.

6. (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.

7. Create new persistent disks in the destination zone from the snapshots you created. First create the boot disk, and then the data disks.

8. Recreate your VM with the new disks in the destination zone.

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

1. Get the details of the VM and identify the disks that are attached to the VM.

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

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

   Note: If you are running a Windows VM, the VM must be terminated before you can create a snapshot. Follow the steps to create a snapshot for Windows VM.

   After you clear your disk buffers, create the snapshots:

4. Delete your VM from the source zone.

5. Next, create another snapshot of both the boot disk and the data disks.

6. (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.

7. Create new persistent disks in the destination zone from the snapshots you created. First create the boot disk, and then the data disks.

8. Recreate your VM with the new disks in the destination zone.

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

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

Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License, and code samples are licensed under the Apache 2.0 License. For details, see the Google Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.

Last updated 2025-08-07 UTC.

[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-08-07 UTC."],[[["This guide explains how to move a virtual machine (VM) to a different zone or region, involving backing up data and recreating the VM."],["Before moving a VM, ensure sufficient project quota for new resources and confirm disks are not attached to other VMs, and local SSD data will not be preserved."],["Moving a VM may result in changes to resource properties, such as a new external IP address when moving between regions, and a potentially different CPU platform depending on the destination zone."],["The process involves creating snapshots of persistent disks, optionally deleting existing resources, creating new disks from snapshots in the target location, and recreating the VM with these new disks."],["Code examples are provided in `gcloud`, Go, Java, Node.js, and Python to illustrate the necessary steps, including managing disk auto-delete settings, creating and deleting snapshots and disks, and recreating VMs with existing disks."]]],[]]

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4