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 Rajini
From: Jean-Philippe Méthot [mailto:jp.met...@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.mcgin...@gmx.com<mailto:sean.mcgin...@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.
_______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
