How to Migrate a VM Between OpenStack Projects

This guide moves a volume-backed instance from a source project into a project in a different domain. What actually moves is the volume (ownership changes); the VM is then booted fresh in the target project.

RISK OF DATA LOSS
This procedure deletes the source instance. If the boot volume’s delete_on_termination flag is set to true, deleting the instance will also delete the volume and all its data permanently. Always verify this flag and create a backup before you start (see Step 0). Proceed only once the volume status is available and the backup has completed successfully.

Prerequisites

  • The instance is volume-backed (boots from a Cinder volume).
  • The boot volume has delete_on_termination = false. Check with:
openstack server show <server> -c volumes_attached
openstack volume show <volume-id> -c name -c status
  • You have credentials for both the source and the target project.

Checking the delete_on_termination flag

This flag is set per volume attachment and is not shown by openstack server show on its own. List the server’s volume attachments instead:

openstack server volume list <server>

Look at the Delete On Termination column:

  • False — safe: deleting the instance keeps the volume.
  • True — the volume and all its data will be deleted together with the instance. Change it to False before you continue (see below).

If the Delete On Termination column is missing or empty, your cloud’s default Compute API microversion is too old to report it. Force a newer one:

openstack --os-compute-api-version 2.89 server volume list <server>

If the flag is True, switch it to preserve-on-termination before deleting the instance (requires Compute API microversion 2.85 or newer):

openstack server volume update --preserve-on-termination <server> <volume-id>

Then re-run openstack server volume list <server> and confirm the column now shows False.

Placeholders

Placeholder Meaning
<server> Name or ID of the instance in the source project
<volume-id> ID of the boot volume
<target-project> Name of the target project
<target-domain> Name of the target domain
<flavor> Flavor for the new instance
<target-net> Network in the target project
<new-name> Name of the new instance in the target project

Step 0 – Create a backup (strongly recommended)

Create a volume backup before touching anything. This is your safety net in case of accidental deletion.

# Full backup of the volume (recommended)
openstack volume backup create --name <volume-id>-pre-move --force <volume-id>

# Watch until the backup reaches status "available"
openstack volume backup show <volume-id>-pre-move -c status

--force allows backing up a volume that is still in-use. Omit it if you have already stopped the instance and detached the volume.

Alternatively, create a snapshot (faster, but stored on the same backend and therefore a weaker safeguard):

openstack volume snapshot create --volume <volume-id> --force <volume-id>-pre-move-snap

Only continue once the backup shows status available.

Step 1 – Release the volume (source project)

openstack server stop <server>
openstack server delete <server>

Only delete if delete_on_termination = false — otherwise the volume will be deleted along with the instance! Afterwards the volume must have status available:

openstack volume show <volume-id> -c status

Step 2 – Create the transfer (source project)

openstack volume transfer request create <volume-id>

Note the transfer ID and the auth_key from the output. The auth_key is shown only once!

Step 3 – Accept the transfer (target project / target domain)

openstack --os-project-name <target-project> --os-project-domain-name <target-domain> \
  volume transfer request accept <transfer-id> <auth_key>

Step 4 – Boot the new VM (target project)

openstack server create \
  --volume <volume-id> \
  --flavor <flavor> \
  --network <target-net> \
  <new-name>

Step 5 – Verify

openstack server show <new-name> -c status -c addresses

Don’t forget

  • Floating IPs, security groups, and keypairs are project-scoped and must be reassigned or recreated in the target project.
  • Make sure the target project’s quotas (vCPUs, RAM, volumes) are sufficient, otherwise Step 4 will fail.

Cancelling a transfer (if needed)

As long as the transfer has not yet been accepted:

openstack volume transfer request list
openstack volume transfer request delete <transfer-id>

Cleaning up the backup

Once the move is confirmed working, you can remove the safety backup to free up space:

openstack volume backup delete <volume-id>-pre-move