[Openstack-operators] Strange behaviour change in cinder with a Dell compellent backend
sean.mcginnis at gmx.com
Tue Apr 24 15:22:40 UTC 2018
On Tue, Apr 24, 2018 at 09:58:26AM +0900, Jean-Philippe Méthot wrote:
> This is a very strange behaviour that has causing me issues with my SAN ever since we upgraded to Mitaka or Ocata I believe, several months ago. Essentially, I used to be able to change the ID of a disk in the SAN to swap the disk in Openstack. So, for example, I had disk 1. I could restore a snapshot of disk 1 on disk 2, rename disk 1 to disk 1-bak and rename disk 2 to disk 1 and the VM would start booting off of the new disk I had just made. This has changed. Now, somehow, Openstack sticks to the original disk even if I rename the disk.
> While annoying, this behaviour didn’t really cause me that many issues. However, I have discovered that if I migrate VMs on which such an operation happened, the VM will try to boot off the original disk from several months ago, despite the new disk being there with the correct ID. How can Openstack find the old disk even if its ID in the SAN has changed?
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.
More information about the OpenStack-operators