IHAC who wonders why when he deletes a volume with NAA 514f0c5272c0000b and creates a new volume, the new NAA identifier is the next 514f0c5272c0000c instead of the re-using the old NAA identifier.
He has two different XtremIO boxes that will be mirrored so he wants to be able to control de NAA in the boxes to be similar to simplify management and troubleshooting.
NAA identifiers are supposed to be globally unique for any and every mapped LUN that you have on any storage array. In your example, part of the NAA string is the array identifier where the LUN is being created – this means that if you create two mapped LUNs on two different storage arrays, they are guaranteed to have different NAAs.
I understand that you are trying to have the two NAA strings to be as similar as possible – but unfortunately the last few characters (which identify the specific LUN) is a monotonously increasing number that starts at 1 for the first LUN assigned an NAA on the array and then goes up with each new NAA assignment. There is no way for you to choose a specific NAA for a specific LUN on the array.
There are unfortunately no documents which I may reference for the exact breakdown of the Volume NAA. Based on my understanding and looking at multiple arrays outputs, I believe the breakdown is as such.
Section in red is the identifying pattern that this came from an XtremIO. This is the same pattern that is used to identify target ports for XtremIO on FC network.
Section in blue is unique identifier for the specific XtremIO array serial number. I am not sure if this is hash of the serial number, how it is derived or if it may actually be one extra character to include the first green zero.
Section in green would be unique number assigned consecutively in order starting from 1 for each mapped volume. In this scenario b converted from hex to decimal is 11. Subtract one as we do not assign 0 as last place holder and we have that this was the 10th volume to be mapped to a host during the history of the array. The array will always increment from the highest assigned LUN NAA. At some point it may have to roll and re-use previously used and released NAA numbers. Again due to lack of documentation, I am going to have to speak in theoretical terms.
Again there is no formal documentation that I have found that breaks down this assignment strategy. This is good trivia data but not a deal breaking data point which will impact ability to administer an XtremIO array.
I can see in very few corner cases of why you would want to. The issue is reusing NAA identifiers for volumes immediately after deletion could cause conflicts on certain hosts that are still looking for the old volume. There are ways to have a snapshot take on the NAA from the original volume during snapshot restores. We can submit an enhancement request for modifying existing volumes but as of right now we do not reuse NAA's until we have run out of 'unique' ones.