For AI agents: the complete documentation index is available at https://docs.ovhcloud.com/es/llms.txt, the full documentation bundle is available at https://docs.ovhcloud.com/es/llms-full.txt, and this page is available as Markdown at https://docs.ovhcloud.com/es/guides/public-cloud/cross-functional/migrating-instance-and-volume-from-local-zone.md.

Migrating a Compute instance and its Block Storage volume from a Local Zone to a 1-AZ or 3-AZ region

Ver como Markdown

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

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

Requirements

  • An instance and a Block Storage volume running in a Local Zone, in the same Public Cloud project 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" 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:
  • 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" 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:

$ 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:

$ 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

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:

$ 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).

Step 2: Export and download the image

Images stored in a Local Zone cannot be downloaded directly with openstack image save. Contact our support 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), 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:

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

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

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

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:

$ openstack volume show test-LZ-MIL -c type -f value
classic

Step 6: Back up the volume 

openstack volume backup create --name backup-test-LZ-MIL --wait test-LZ-MIL

Check that the backup is available:

$ 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 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:

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 (classic in this example), unless you deliberately want a different one — the storage class affects both performance and billing:

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:

$ 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:

$ 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:

$ 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:

$ 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

Migration of instances between different regions

Downloading and transferring an instance backup from one OpenStack region to another

Local Zone Compute - Features, Capabilities and Limitations

Join our community of users.

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.

¿Le ha resultado útil esta página?