Skip to main content

​
Overview

Volume migration copies all volume data to a different backend while preserving volume identity, metadata, and attachment state. Migration is used to rebalance capacity across backends, retire storage hardware, or move volumes to a higher or lower performance tier. Xloud Block Storage supports two migration modes: backend-assisted migration (when backends share a storage layer) and host-copy migration (a full data copy between independent backends).
Administrator Access Required — This operation requires the admin role. Contact your Xloud administrator if you do not have sufficient permissions.
Prerequisites
  • Administrator credentials with the admin role
  • The destination backend must be registered and have sufficient free capacity
  • Identify the destination host with openstack volume service list

​
Migration Modes

ModeWhen UsedDurationImpact
Backend-assistedSource and destination share the same storage clusterSeconds to minutes (metadata only)Minimal — no data copy
Host-copyIndependent backends (different clusters)Minutes to hours depending on volume sizeI/O overhead during copy
Volume migration copies all data to the destination backend. Duration depends on volume size and available network/storage bandwidth. Schedule large migrations during off-peak hours to minimize impact on running workloads.

​
Migrate a Volume

Locate the volume

Log in to the Xloud Dashboard (https://connect.<your-domain>) and navigate to Admin → Volumes → Volumes. Use the search or filter to find the target volume.

Initiate migration

Click Actions → Migrate Volume. Select the destination backend from the Destination Host dropdown.Enable Force Host Copy only if the backends do not share a storage layer and backend-assisted migration is not possible.Click Migrate.

Monitor progress

The volume status changes to migrating. Refresh the volume list periodically to track progress. On completion, status returns to available and the Hosted At field updates to the destination backend.
Migration complete — volume is now on the destination backend.

​
Migrate Multiple Volumes (Backend Retirement)

To retire a backend, migrate all volumes off it before decommissioning:

List volumes on the backend to retire

List volumes on a specific backend
openstack volume list --all-projects \
  --host <backend-host-to-retire>

Disable the backend service

Prevent new volumes from being scheduled to the retiring backend:
Disable backend service
openstack volume service set \
  --disable \
  --disable-reason "Scheduled for retirement" \
  <backend-host> \
  cinder-volume

Migrate all volumes

Run migration for each volume listed in Step 1:
Migrate each volume
openstack volume migrate --host <destination-host> <volume-id>
For large numbers of volumes, use a loop:
Batch migration
for vid in $(openstack volume list --all-projects --host <old-host> -f value -c ID); do
  openstack volume migrate --host <new-host> "$vid"
done

Verify all migrations complete

Check for remaining volumes on old backend
openstack volume list --all-projects --host <old-host>
No volumes remaining on the retired backend — safe to decommission.

​
Troubleshooting

Symptom: Volume status remains migrating for an extended period with no progress.Resolution:
Check migration status and logs
openstack volume show <volume-id> -c migration_status -c status
Check volume service logs on the source and destination nodes via XDeploy for migration-related errors.If the migration is permanently stuck, reset the volume state:
Reset volume state (admin only)
openstack volume set --state available <volume-id>
Resetting the volume state does not undo a partial migration. Verify data integrity on both the source and destination backends before resetting. In some cases, partial data may exist on both backends.
Cause: The destination backend does not have enough free capacity to accommodate the volume.Resolution:
Check destination backend capacity
openstack volume backend pool list --long
Select a different destination with sufficient free capacity, or free up space on the intended destination backend.

​
Next Steps

Storage Backends

Configure and manage backend drivers and capacity

Storage Tiers

Configure multi-tier storage to give users tier selection at volume creation

Quotas

Monitor and manage storage quota allocation across projects

Admin Guide

Return to the Block Storage administration overview