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> 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
