[Openstack-operators] Strange behaviour change in cinder with a Dell compellent backend
jp.methot at planethoster.info
Wed Apr 25 02:09:59 UTC 2018
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.
Openstack system administrator
Administrateur système Openstack
> Le 25 avr. 2018 à 00:22, Sean McGinnis <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...
More information about the OpenStack-operators