Retyping with migrate to new backend not renaming volume on backend device

Solution Verified - Updated -

Issue

  • We encountered an issue with volume migration between different arrays. The migration failed because the cinder driver want to use the obsolete volume ID to find source LUN. , the migrated volume gets referred by its old UUID instead of the new one. Then the driver uses this ID to locate the volume in the array and fails.
cinder create --display-name backend_retype_kaihua --volume-type xio_normal 1
Succeed. volume 0975f53d-abda-4147-8d6c-58f1e897e417 is created on XtremIO box

cinder retype backend_retype_kaihua vmax_normal --migration-policy on-demand
Succeed to move the LUN to VMAX . a new LUN is created on VMAX box and we see the volume copy is done.

cinder retype backend_retype_kaihua xio_normal --migration-policy on-demand
Succeed to move the LUN to XtremIO, a new LUN is created on xtremIO box and we see the volume copy is done.

cinder retype backend_retype_kaihua vmax_normal --migration-policy on-demand
FAILED. It seems that the cinder volume wants to detect the LUN ID using the original volume ID. But in xtremIO box, the LUN ID isn’t related with the original volume ID recorded by cinder.

2015-09-17 04:36:10.545 14971 WARNING cinder.volume.drivers.emc.xtremio [req-350dd938-a721-4660-8447-44e38a133d8d - - - - -] object None of type lun-maps not found
2015-09-17 04:36:10.548 14971 ERROR cinder.volume.driver [req-350dd938-a721-4660-8447-44e38a133d8d - - - - -] Unable to fetch connection information from backend: Resource could not be found.
2015-09-17 04:36:10.549 14971 ERROR cinder.volume.driver [req-350dd938-a721-4660-8447-44e38a133d8d - - - - -] Failed to attach volume 0975f53d-abda-4147-8d6c-58f1e897e417

Environment

Red Hat Openstack Platform 7

Subscriber exclusive content

A Red Hat subscription provides unlimited access to our knowledgebase of over 48,000 articles and solutions.

Current Customers and Partners

Log in for full access

Log In