Putting on the storage admin hat.. you have to remember the little details that a good storage admin knows instinctively. I was assisting a customer with allocating new LUNS to their file system (CIFS/ NFS)… and well I gave general high level instruction but after the customer had some errors.. here are the lessons learned.
Host LUN ID.
It is important.
For example.. a boot LUN needs to have HLU = 0
That is important when you boot from SAN.
For example each ESXI must have a separate storage group for the boot LUN, as there can only be on HLU = 0 per storage group.
Also: HLU IdS 6 to 15 are reserved for system use only
Now this is different than a LUN ID.
When adding a LUN to a storage group; this is the opportunity (or only time) you have to change the HLU ID.
BUT if you forgot and didn’t pay attention when adding LUNS to your storage group..
(This is disruptive. You will lose all data on LUN as it has a new HLUID)
1. remove LUNS from storage group.
2. re-assign LUNS to storage group; remember to assign HLU ID at this time >16
3. I try to match ID with HLU ID if possible.
Possible errors is HLU ID is <16
SCAN failure message = Message ID 1360601492
SCAN from GUI (unisphere) or
from CLI: nas_diskmark -m -a (login to Control Station as NASADMIN and run cli)
Also.. when dealing with VNX file systems. Do not remove backend LUN without first removing dvols.
Without deleting dvol you should not remove backend LUN.. there is some binding that happens between the two.. and well, let's just say your storage pool for file really doesn't like it.
clarsas_archive what the heck??
What is it?
"This a system definded pool. If you create a RAID group at the backend with RAID 5 type and add the LUNs from that RG to ~fs group. It will automatically create a file pool by name clarsas_archive"
Well I don't want it around.. the remove dvols and then remove the supporting backend LUNS.
Just a few VNX storage tips. Hope you find it helpful.. be social, share.