Unsolved
This post is more than 5 years old
7 Posts
1
7852
How to create a LUN with a matching or specific HOST LUN ID
I thought I'd post a how to on this since there doesn't seem to be clear instruction.
This is on a VNX 5300
First, if you use the wizard, or use the "Add to Storage Group" button from the LUN page, it will assign a default incremented HOST LUN ID, and you'll be unable to change it. So, don't do that.
Create the LUN, let's say for this example we want the ID and the HOST LUN ID to be 200. So we'll create a new lun,
Name - LUN 200
Use the "LUN ID" dropdown to scroll down and pick "200" like the screenshot below;
Click apply and it will create that LUN. Now you're DONE on this page.
Next, go to "Hosts" and click on "storage groups" as noted here;
When that opens, right click on the storage group specified during creation and click "select LUNS". I will open the screenshot below. Click on the LUN tab and expan the SPAs in the tree view and find the lun you just created. See highlighted sections;
Highlight the LUN 200 and click on the "ADD" button. You will see it show up in the bottom pane with no HOST LUN ID set. Like this;
Now, take your mouse cursor and click directly on the blank Host LUN ID cell and it will show a drop down box which lets you select it;
Chose 200 there;
now click on "Apply" and you have a LUN where the LUN ID and the HOST LUN ID match;
You cannot change existing ones. The only way to change the HOST LUN ID of an existing LUN is to remove it from the storage group. That destroys the data on that LUN, so you better know what you're doing if you try that. Hopefully this will help show how to specify a HOST LUN ID if you want to in your environment. JL
christopher_ime
2K Posts
1
June 20th, 2013 20:00
jlackman,
Great post. I love the screenshots and can appreciate the time it took to put this together. As you point out, it brings awareness as many people do not realize that you don't have to accept the default allocation of the Host ID (starting by 0 and incrementing by 1 in the order they are added) and can actually click into the field only at the time of assigning to the storage group.
The only main thing I want to clarify (sorry I don't mean to take anything away from this) is that the act of removing the LUN from the storage group, in itself, and even changing the Host ID (HLU) won't destroy the data as you suggest. On the other hand, I do want to mention that if not done gracefully there is risk of data corruption and/or lost data (host/OS cache). For instance, making sure applications accessing that LUN are no longer referencing it, and then also unmounting it properly to also flush any host/OS cache before you remove it from the storage group is the prudent thing to do.
Also, while not wrong, your post suggests that LUN ID should match Host ID (versus just assigning in contiguous order incrementing by 1 starting at 0 regardless of its ALU/LUN ID). For many OS's that will work fine and obviously this is the case for your environment; however, I do want to mention the following caveats:
1) Some OS's that rely on the Host ID for device assignment may not like the non-contiguous order or in other words any gaps.
For instance, in ESX/ESXi there is a setting Disk.SupportSparseLUN. Now it is enabled by default, but if it were disabled then say you had presented LUNs with Host ID (HLU) of 0, 1, 2, 4, 5. Note that 3 was skipped, then the host would only see LUNs 0, 1, 2.
2) Some OS's may not see any Host ID greater than 255 (0 - 255)
Again, using ESX/ESXi as an example, an ESX/ESXi Advanced Setting: Disk.MaxLUN if set to 256 suggests not only a quantity of LUNs but in some versions prior to vSphere where CTL was the device label for storage, it would also ignore anything past what was set (255 in this example remembering that the index starts at 0).
3) While your screenshots clearly show it, I want to emphasize that you should always mask out LUNZ (by assigning a LUN with Host ID of 0).
Perfectly shown in your example.