[Openstack-operators] Strange behaviour change in cinder with a Dell compellent backend

Rajini.Karthik at Dell.com Rajini.Karthik at Dell.com
Thu Apr 26 15:23:35 UTC 2018

Dell - Internal Use - Confidential

We track the SAN’s internal ID for the volume. This isn’t something that the user can create. Your options are to change the OpenStack database provider_id for the volume to match the new ID.
Hope this helps

From: Jean-Philippe Méthot [mailto:jp.methot at planethoster.info]
Sent: Tuesday, April 24, 2018 9:10 PM
To: Sean McGinnis
Cc: openstack-operators
Subject: Re: [Openstack-operators] Strange behaviour change in cinder with a Dell compellent backend

Thank you for your reply. This implies that the SAN keeps track of a volume’s native ID. So, for example, if I had a VM that was trying to mount an inexistant volume ID after migration, I could fix this by creating a new volume with the proper ID and just migrate the data from the volume that was in-use previously. That was my main concern and now it does make the process of fixing this simpler.

Jean-Philippe Méthot
Openstack system administrator
Administrateur système Openstack
PlanetHoster inc.

Le 25 avr. 2018 à 00:22, Sean McGinnis <sean.mcginnis at gmx.com<mailto:sean.mcginnis at gmx.com>> a écrit :

If I remember right, this was a fix in the driver to be able to track the
volume by its native array ID and not its name. This is how things should work.
Reliance on the name of the volume is not safe, and as seen here, can be
misused to do things that are not really supported and can cause some
unintended side effects.

You can update the database to get the same (mis)behavior you were using, but I
am not suggesting that is a good thing to do.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20180426/84721b0c/attachment.html>

More information about the OpenStack-operators mailing list