--- title: "Migrating a Compute instance and its Block Storage volume from a Local Zone to a 1-AZ or 3-AZ region" description: "Find out how to migrate a Public Cloud instance and its attached Block Storage volume from a Local Zone to a 1-AZ or 3-AZ region, using the OpenStack CLI" url: https://docs.ovhcloud.com/de/guides/public-cloud/cross-functional/migrating-instance-and-volume-from-local-zone lang: de lastUpdated: 2026-09-16 --- > For AI agents: the complete documentation index is available at https://docs.ovhcloud.com/de/llms.txt, the full documentation bundle is available at https://docs.ovhcloud.com/de/llms-full.txt. # Migrating a Compute instance and its Block Storage volume from a Local Zone to a 1-AZ or 3-AZ region ## Objective A Local Zone and a 1-AZ or 3-AZ region are two distinct OpenStack regions. An instance or a volume cannot be moved directly between them: export both as images, then re-import and re-create them in the target region. **This guide explains how to migrate a Compute instance and its attached Block Storage volume from a Local Zone to a 1-AZ or 3-AZ region, using the OpenStack CLI.** It is illustrated with the following example: - A `b3-16` instance running in the Milan Local Zone (`EU-SOUTH-LZ-MIL-A`), with an attached Block Storage volume. - Both are migrated to the Milan 3-AZ region (`EU-SOUTH-MIL`). The same steps apply to any other Local Zone and its parent 1-AZ or 3-AZ region. :::info Before migrating, it's worth understanding the differences between the deployment modes offered by OVHcloud Public Cloud. Each mode (1-AZ, 3-AZ or Local Zones) has a direct impact on the resilience, availability and design of your infrastructure. To find out more, consult "[Comparison and resilience of Deployment Modes - Understanding 3-AZ / 1-AZ / Local Zones](https://docs.ovhcloud.com/de/guides/public-cloud/cross-functional/deployment-modes-comparison-resilience-details.md)". ::: ## Requirements - An instance and a Block Storage volume running in a Local Zone, in the same [Public Cloud project](https://www.ovhcloud.com/de/public-cloud/) as the target 1-AZ or 3-AZ region. - The OpenStack CLI, installed and ready to use. Follow our guide "[Preparing an environment for using the OpenStack API](https://docs.ovhcloud.com/de/guides/public-cloud/cross-functional/compute-prepare-openstack-api-environment.md)" if this is not already the case. - Enough local disk space to temporarily hold the exported image and the volume backup (at least the size of the instance's system disk plus the size of the volume). *** ### OVHcloud Control Panel Access - **Direct link:** All my Public Cloud projects - **Navigation path:** Public Cloud > Select your project *** ## Instructions ### Retrieve OpenStack credentials for both regions You need OpenStack credentials (an OpenRC file) for **both** the source Local Zone and the target 1-AZ or 3-AZ region: they are two regions of the same OpenStack project. To download an OpenRC file: 1. Under **Settings**, open Users & Roles. 2. Next to the relevant user, click the ... button, then select Download OpenStack's RC file. 3. In the dialog box, first select your **Local Zone** (e.g. `Milan (EU-SOUTH-LZ-MIL-A)`), then click Download. 4. Repeat the operation, this time selecting the corresponding **1-AZ or 3-AZ region** (e.g. `EU-SOUTH-MIL`). :::info An OpenRC file pins a single user and a single region, through the `OS_REGION_NAME` variable it exports. Both regions belong to the same OpenStack project, so the same credentials apply to each: to switch region, either source the other file, or override that variable in the current shell (`export OS_REGION_NAME=EU-SOUTH-MIL`). See our guide "[Setting OpenStack environment variables](https://docs.ovhcloud.com/de/guides/public-cloud/cross-functional/compute-set-openstack-environment-variables.md)" for details on sourcing an OpenRC file. ::: ### Overview of the migration For the **Compute instance**: 1. Create an image from the Local Zone instance (this does not include its attached volumes). 2. Export and download that image. 3. Upload the image to the 1-AZ or 3-AZ region. 4. Create a new instance from this image. For the **Block Storage volume**: 1. Detach the volume from the instance. 2. Create a backup of the Local Zone volume. 3. Export and download that backup as an image. 4. Upload the image to the 1-AZ or 3-AZ region. 5. Create a new volume from this image, and attach it to the migrated instance. :::info To keep the data consistent, it is recommended to power off the source instance before starting the migration. ::: ### Prepare the source instance and volume [](#) Source the OpenRC file for the source Local Zone, then identify the instance and the volume to migrate: ```bash $ openstack server list +--------------------------------------+-------------+--------+----------------------------------------------------------------+--------------+--------+ | ID | Name | Status | Networks | Image | Flavor | +--------------------------------------+-------------+--------+----------------------------------------------------------------+--------------+--------+ | 62abae51-f521-416a-9d14-0fcff617cb8a | test-LZ-MIL | ACTIVE | Ext-Net=xx.xx.xx.xx, xx:xx::xx:xx:xx; test-LZ-MIL=xx.xx.xx.xx | Ubuntu 26.04 | b3-16 | +--------------------------------------+-------------+--------+----------------------------------------------------------------+--------------+--------+ $ openstack volume list +--------------------------------------+-------------+--------+------+-------------------------------------+ | ID | Name | Status | Size | Attached to | +--------------------------------------+-------------+--------+------+-------------------------------------+ | 39312ab3-f855-41ab-baeb-b24a6ebed79b | test-LZ-MIL | in-use | 10 | Attached to test-LZ-MIL on /dev/sdb | +--------------------------------------+-------------+--------+------+-------------------------------------+ ``` A volume can only be backed up once it is detached (status `available`). Detach it from the instance — the first argument is the server, the second the volume, and here both are named `test-LZ-MIL`: ```bash $ openstack server remove volume test-LZ-MIL test-LZ-MIL $ openstack volume list +--------------------------------------+-------------+-----------+------+-------------+ | ID | Name | Status | Size | Attached to | +--------------------------------------+-------------+-----------+------+-------------+ | 39312ab3-f855-41ab-baeb-b24a6ebed79b | test-LZ-MIL | available | 10 | | +--------------------------------------+-------------+-----------+------+-------------+ ``` ### Part 1 — Migrate the Compute instance #### Step 1: Create an image of the instance ```bash openstack server image create --name image-test-LZ-MIL --wait test-LZ-MIL ``` The `--wait` flag makes the command return only once the image is `active`. You can also check its status separately: ```bash $ openstack image list --name image-test-LZ-MIL +--------------------------------------+-------------------+--------+ | ID | Name | Status | +--------------------------------------+-------------------+--------+ | 4ba54315-4c98-46ab-a098-f834d02b0e35 | image-test-LZ-MIL | active | +--------------------------------------+-------------------+--------+ ``` :::info This image only captures the instance's system disk — attached Block Storage volumes are not included and must be migrated separately (see [Part 2](#part2-volume-migration)). ::: #### Step 2: Export and download the image Images stored in a Local Zone cannot be downloaded directly with `openstack image save` . Contact our [support](https://help.ovhcloud.com/csm?id=csm_get_help) and ask them to export the image — you will receive a pre-signed S31 URL to download it. Once downloaded, uncompress the file if necessary. :::info If you have already created the volume backup as well (see [Part 2, Step 6](#step-6)), you can ask support to export both the instance image and the volume backup in the same request, to avoid a second round trip. ::: #### Step 3: Upload the image to the target region Source the OpenRC file for the target 1-AZ or 3-AZ region (or switch by setting `OS_REGION_NAME` to it, here `EU-SOUTH-MIL`), then upload the image: ```bash openstack image create \ --file image-test-LZ-MIL \ --disk-format raw \ --container-format bare \ image-test-3AZ-MIL ``` :::warning The disk format must be `raw`, not `qcow2`. Depending on the image size, the upload can take a while — let it complete. ::: #### Step 4: Create the instance in the target region Create the new instance from the uploaded image: - Choose a flavor whose system disk is at least as large as the source instance's. In this example, `b3-16` has a 100 GB system disk and is available with identical specifications in both the Local Zone and the 3-AZ region. - Specify the [availability zone](https://docs.ovhcloud.com/de/guides/public-cloud/cross-functional/deployment-modes-comparison-resilience-details.md) where the instance should be created. A 1-AZ region has a single availability zone, so `--availability-zone` is optional there; a 3-AZ region has three, so choose the one you want explicitly. - The `default` security group already exists in every project and is enough to get started; customise it later by following "[Creating and configuring a security group in Horizon](https://docs.ovhcloud.com/de/guides/public-cloud/compute/setup-security-group.md)". - If you don't have an SSH key pair yet (`my_key` in the example below), create one following the **Creating key pairs for OpenSSH connections** section of "[How to create and use authentication keys for SSH connections to Public Cloud instances](https://docs.ovhcloud.com/de/guides/public-cloud/compute/creating-ssh-keys.md)". - The instance needs an existing network (`test-3AZ-MIL` in the example below). To create one with a Gateway via the OpenStack CLI, follow the **Create a private network with a Gateway** section of "[Creating a private network with Gateway](https://docs.ovhcloud.com/de/guides/public-cloud/network-services/create-private-network-gateway.md)". - To reach the instance from the Internet, attach a Floating IP following the **Via the OpenStack API** section (under "Attaching a Floating IP to an instance") of "[Attaching a Floating IP to a Public Cloud instance](https://docs.ovhcloud.com/de/guides/public-cloud/network-services/attach-floating-ip-to-instance.md)". ```bash openstack server create \ --flavor b3-16 \ --image image-test-3AZ-MIL \ --network test-3AZ-MIL \ --security-group default \ --key-name my_key \ --availability-zone eu-south-mil-b \ test-3AZ-MIL ``` Wait until the instance reaches the `ACTIVE` status: ```bash $ openstack server list --name test-3AZ-MIL +--------------------------------------+--------------+--------+---------------------------+--------------------+--------+ | ID | Name | Status | Networks | Image | Flavor | +--------------------------------------+--------------+--------+---------------------------+--------------------+--------+ | 90d2a04a-3aad-40f3-99bb-c561348aee0e | test-3AZ-MIL | ACTIVE | test-3AZ-MIL=192.168.0.46 | image-test-3AZ-MIL | b3-16 | +--------------------------------------+--------------+--------+---------------------------+--------------------+--------+ ``` #### Step 5: About the first boot The volume has not been migrated yet, so the boot process will not complete: the console log will show the system waiting for the missing disk and eventually dropping into emergency mode. This is expected — it confirms the image itself is correct. ```bash $ openstack console log show test-3AZ-MIL | tail -6 [ TIME ] Timed out waiting for device dev-disk-by\x2dlabel-data.device - /dev/disk/by-label/data. [DEPEND] Dependency failed for systemd-fsck-data.service - File System Check on /dev/disk/by-label/data. [DEPEND] Dependency failed for mnt-data.mount - /mnt/data. [DEPEND] Dependency failed for local-fs.target - Local File Systems. [ OK ] Reached target emergency.target - Emergency Mode. You are in emergency mode. After logging in, type "journalctl -xb" to view system logs... ``` Continue with the volume migration below, then attach the volume and restart the instance — the boot will then complete normally. :::info If your `fstab` mounts the volume by device name (e.g. `/dev/vdb`) rather than by `LABEL` or `UUID`, the device name may differ once the volume is re-attached, and the boot could fail again — in this example the volume moves from `/dev/sdb` on the Local Zone to `/dev/vdb` in the 3-AZ region. Using `LABEL=` in `fstab` avoids this. If the instance is already unreachable, boot it in [rescue mode](https://docs.ovhcloud.com/de/guides/public-cloud/compute/put-an-instance-in-rescue-mode.md) to fix `fstab`. ::: ### Part 2 — Migrate the Block Storage volume [](#) The volume must still be detached (status `available`), as set up in [Prepare the source instance and volume](#prepare-source). Part 1 ended on the target region, so switch back to the source Local Zone: the command below and Step 6 run against it, and Step 8 switches to the target region again. Note the source volume's storage class — you will reuse it for the new volume in Step 9: ```bash $ openstack volume show test-LZ-MIL -c type -f value classic ``` #### Step 6: Back up the volume [](#) ```bash openstack volume backup create --name backup-test-LZ-MIL --wait test-LZ-MIL ``` Check that the backup is `available`: ```bash $ openstack volume backup list +--------------------------------------+--------------------+-------------+-----------+------+-------------+----------------------------+ | ID | Name | Description | Status | Size | Incremental | Created At | +--------------------------------------+--------------------+-------------+-----------+------+-------------+----------------------------+ | 5d0f8780-8dc2-4a39-a14a-b3e2a8c7c182 | backup-test-LZ-MIL | None | available | 10 | False | 2026-08-10T14:11:35.000000 | +--------------------------------------+--------------------+-------------+-----------+------+-------------+----------------------------+ ``` #### Step 7: Export and download the backup As with the instance image, contact our [support](https://help.ovhcloud.com/csm?id=csm_get_help) and ask them to export the volume backup as an image. You will receive a pre-signed S3 URL to download it, and can uncompress the file if necessary. #### Step 8: Upload the backup image to the target region Once you have switched back to the target 1-AZ or 3-AZ region: ```bash openstack image create \ --file backup-test-LZ-MIL \ --disk-format raw \ --container-format bare \ volume-backup-test-LZ-MIL ``` :::warning The disk format must be `raw`, not `qcow2`. Depending on the image size, the upload can take a while — let it complete. ::: #### Step 9: Create the volume from the image Create the volume with the storage class noted at the start of [Part 2](#part2-volume-migration) (`classic` in this example), unless you deliberately want a different one — the storage class affects both performance and billing: ```bash openstack volume create \ --image volume-backup-test-LZ-MIL \ --availability-zone eu-south-mil-b \ --type classic \ --size 10 \ test-3AZ-MIL ``` :::info - `--size` must be at least the size of the original volume. - `--availability-zone` must match the instance's availability zone if you are using the `high-speed` or `high-speed-gen2` storage class. In a 1-AZ region there is only one possible value; in a 3-AZ region, match the zone chosen for the instance in Step 4. ::: Wait until the volume is `available`: ```bash $ openstack volume list --name test-3AZ-MIL +--------------------------------------+--------------+-----------+------+-------------+ | ID | Name | Status | Size | Attached to | +--------------------------------------+--------------+-----------+------+-------------+ | 6e7f5de3-672f-4d00-9636-9679f8b561cb | test-3AZ-MIL | available | 10 | | +--------------------------------------+--------------+-----------+------+-------------+ ``` #### Step 10: Attach the volume and restart the instance Stop the instance, attach the volume, then start it again: ```bash $ openstack server stop test-3AZ-MIL ``` Wait until the instance reaches the `SHUTOFF` status. As in the source region, the first argument of `server add volume` is the server and the second the volume — here both are named `test-3AZ-MIL`: ```bash $ openstack server add volume test-3AZ-MIL test-3AZ-MIL $ openstack server start test-3AZ-MIL ``` Because `fstab` references the volume by `LABEL`, the system discovers and mounts it automatically, and the boot completes: ```bash $ ssh ubuntu@xx.xx.xx.xx hostname test-3az-mil $ ssh ubuntu@xx.xx.xx.xx df -h /mnt/data Filesystem Size Used Avail Use% Mounted on /dev/vdb1 9.8G 5.1G 4.3G 55% /mnt/data ``` The instance and its Block Storage volume are migrated to the target region. ## Go further [Comparison and resilience of Deployment Modes - Understanding 3-AZ / 1-AZ / Local Zones](https://docs.ovhcloud.com/de/guides/public-cloud/cross-functional/deployment-modes-comparison-resilience-details.md) [Migration of instances between different regions](https://docs.ovhcloud.com/de/guides/public-cloud/compute/migration-between-regions.md) [Downloading and transferring an instance backup from one OpenStack region to another](https://docs.ovhcloud.com/de/guides/public-cloud/compute/transfer-instance-backup-from-one-datacentre-to-another.md) [Local Zone Compute - Features, Capabilities and Limitations](https://docs.ovhcloud.com/de/guides/public-cloud/compute/local-zones-capabilities-limitations.md) Join our [community of users](https://community.ovhcloud.com/). 1 : S3 is a trademark of Amazon Technologies, Inc. OVHcloud's service is not sponsored by, endorsed by, or otherwise affiliated with Amazon Technologies, Inc.