Unsolved
This post is more than 5 years old
44 Posts
0
6851
Trying to destroy LUN, states is in use - unable to find where...
Hi All -
Very frustrating issue here... Looks as though a LUN was created for mirrorview to mirror a Production LUN to the DR array (CX4-240). I cannot find anywhere that this LUN is being used on the DR array. When I try to delete the LUN, it tells me the normal 'in use' message.
LUN 51 - Could not be destroyed.
It is participating in one of the following storage features:
1)Storage Group
2)Snapshot
3)Clone
4)SAN Copy
5)MirrorView
6)MetaLUN
7)LUN Migration
For the life of me I cannot find where this LUN is being used at all, I have checked each of the 'features' mentioned above. What tests/reports can I run to figure out what it is attached to? I have went through the whole production array and I do not see where this DR LUN is being used as a secondary LUN with anything. I have went through the DR array and do not see where someone might have set it up as a primary LUN anywhere. I am sure I am missing something.
Thank you in advance.
Govindagouda
85 Posts
0
June 14th, 2011 08:00
Have you Checked the Reserverd Lun Pool. check if it is part of it. Then remove it.
Gouda2
20 Posts
0
June 14th, 2011 08:00
I know you might have checked this too.
how about clone Private Lun.
TCLiven
44 Posts
0
June 14th, 2011 08:00
Thank you for responding. I did check the reserved LUN pool on the DR array and it is not being used there.
TCLiven
44 Posts
0
June 14th, 2011 09:00
yeah.. private lun, metalun, unowned luns... I cannot find it anywhere.. blah. Is there a report that I can run on the mac address and see what all it may be allocated to ?
Kumar_A
727 Posts
1
June 14th, 2011 11:00
You can use the command "getlun -messner lun# -stack" to find which layered driver is using the LUN.
Govindagouda
85 Posts
0
June 15th, 2011 06:00
I have executed the command but even though the LUNS used by the host it doesnt give any results
C:\>naviseccli -h 192.168.88.91 getlun -messner 24 -stack
Listed Driver:
C:\>naviseccli -h 192.168.88.91 getlun -messner 103 -stack
Listed Driver:
TCLiven
44 Posts
0
June 15th, 2011 06:00
Thanks Avi - how do I run this command from within Navisphere?
Kumar_A
727 Posts
0
June 15th, 2011 06:00
Yes, this is a CLI command. You need to install naviseccli on a host with IP connectivity to the storage system. You can then run the command.
naviseccli -h -user -password -scope 0 getlun ...
Madhug1
127 Posts
0
June 15th, 2011 07:00
If you are not able to see any driver information from Naviseccli, try restarting the management server of both SPA and SPB.
To restart the management server, http://SPA_IP_ADDRESS/setup and http://SPB_IP_ADDRESS/setup
Login and Click on Restart Management Server and Click on Yes to restart
Perform this action on both SPA and SPB
Logout of Navisphere and Login Again.
Then try deleting the LUN.
Thanks
Madhusudan
Kumar_A
727 Posts
0
June 15th, 2011 07:00
The CLI command tells you if there are any layered drivers using up that LUN. Did you have any layered driver (for example, mirrorview, etc) being used on that LUN when you ran that command?
TCLiven
44 Posts
0
June 15th, 2011 08:00
I always get confused on restarting the SP's. I CAN do this without affecting production, correct? I am still new to this SAN admin stuff but have just had a ton of stuff taken off my plate to really dig into it!
Kumar_A
727 Posts
0
June 15th, 2011 08:00
What Madhusudan has suggested is not restarting the SP, you will just restart the management server on both the SPs. this will not cause any disruption to the host IO on your SPs.
TCLiven
44 Posts
0
June 15th, 2011 08:00
Hmm.. OK - it looks as though it 'thinks' the attached is working on it... Interesting...
TCLiven
44 Posts
0
June 15th, 2011 08:00
that is what I meant.. sorry for the confusion! thanks. will report back
TCLiven
44 Posts
0
June 15th, 2011 09:00
buggers.. did not help obviously I am just blind and something really is accessing this darn LUN. I have a support call scheduled with EMC this afternoon regarding RM, so I will hit them up with this one too.