One of the cool features offered by OpenStack is the migration of Cinder volumes across backends. Volumes can be moved within an ONTAP cluster, between ONTAP clusters and between an ONTAP and SolidFire cluster. The good thing about migrating volumes is that the operation is transparent to the end user. From the user’s perspective, they are not aware that the volume has been moved between clusters/across clusters. In fact, this migration of volumes is non-disruptive as well! The volume can be attached to an instance and have active operations, without having to worry about disruption of data transfer. This provides a very useful mechanism for admins to move Cinder volumes between storage clusters, as and when they are expanding their infrastructure and scaling out, or if they decide to decommission storage. This feature has been supported since the Newton release of OpenStack.

Welcome to part one of a three-part series discussing volume migration on Openstack with NetApp. In this series, we will be looking at the following concepts:

  • A brief discussion on Cinder volume migration and its internals
  • Migrating Cinder volumes between backends on the same cluster (Intracluster migration)
  • Migrating Cinder volumes between backends present on different clusters (Intercluster migration)

So how does this work? The sequence of steps that are taken to make this work vary, depending on the status of the volume in question.

Case 1: Migrating an unattached volume.

When a Cinder volume that is not attached to a compute instance is to be migrated (in the “available” state), the procedure is as follows: Cinder creates a new volume on the destination backend and copies data from the source volume to the destination volume. After quiescing the data, Cinder updates the UUID for the destination volume to be that of the source and destroys the source volume. In this manner, the metadata associated with the volume remains the same after migration.

Case 2: Migrating a volume that is attached to an instance.

What if the volume is attached to an instance (in the “in-use” state)? The procedure is a little more complicated, as this requires Nova and Cinder to communicate with each other. When a migrate request is received, Cinder first creates a destination volume on the backend, and attaches it to the instance in question. It then hands over the control to Nova, which is responsible for quiescing the data between the two volumes. Any active operations begin writing to a cache, whose contents are copied to the newly created volume. Subsequently, the attachments are updated (the old volume is detached and marked to be removed, the newly created volume is detached and reattached at the same device as the old volume, and the UUID is retained).

Requirements and limitations

There are certain limitations and requirements that must be satisfied to perform volume migration:

  • Migration is an administrator functionality and cannot be performed by non-admin users.
  • Certain operations such as attaching/detaching the volume to an instance, deleting the volume and taking snapshots of the volume are not permitted when a migration is taking place.
  • As of the Rocky release, it is not possible to migrate a volume with snapshots.

Currently, NetApp does not offer optimizations for volume migration and this functionality is achieved by the generic implementation provided by Cinder. This feature is available from the Newton release.

Does it have to be the same volume type?

Short answer: No. Migrating a volume between backends belonging to the same volume type can be accomplished using the cinder migrate command. What happens if the administrator wants to convert the type of the volume altogether? This can also be done. To initiate a volume migration by converting the volume from one cinder volume type to another, the cinder retype command must be used. This can internally trigger a volume migration, based on the backends associated with the destination cinder volume type.

Read part 2 of this series to learn about intracluster migration and part 3 for specifics of cross-cluster migrations.

Checkout our Deployment and Operations Guide for comprehensive information on our OpenStack offerings. Join us on our Slack channel to provide feedback and post questions. As always more information can always be found at

About Bala RameshBabu

Bala is a Technical Marketing Engineer who focuses on Trident, NetApp's dynamic storage provisioner for Kubernetes and Docker. With a background in OpenStack, he focuses on open-source solutions and DevOps workflows. When not at work, you can find him in a soccer field or reading biographies

Pin It on Pinterest