This post is more than 5 years old
2 Intern
•
157 Posts
0
2018
September 26th, 2014 08:00
naviseccli lun command fails
hi all
Working on a script to get lun info from an old array before configuring a new array and I can get the list of luns using the server -volmap command, then I go after each lun to get details about capacity and uid, etc but for many luns it cannot find them. I don't get it. Attached is just one example. The getlun # command returns all the details about the "missing" luns, but the lun command alone fails with the error "Could not retrieve the specified (lun). The (lun) may not exist. WTH?
Of course I could extract this info by parsing info from other commands but the lun command options make it real easy to get what I need without much trouble.
thanks
kelleg
4.5K Posts
0
September 29th, 2014 15:00
The LUN command was added in Flare 30 to support the Virtual Pool. What specific information are you looking for that you can get with the LUN, but not with the getlun?
glen
downhill2
2 Intern
•
157 Posts
0
September 26th, 2014 11:00
Yep. Tried that. Tried running the command from both windows and linux, no diff. Of course, my script is already to chug through 100’s of LUNs and right off the bat “fail”.
thanks
dynamox
9 Legend
•
20.4K Posts
0
September 26th, 2014 11:00
what happens when you run "naviseccli -h 1.1.1.4 lun -list -l 305". Maybe LUN 305 is not a pool LUN ?
downhill2
2 Intern
•
157 Posts
0
September 26th, 2014 11:00
I thought I had that in the attachment, I get the same result. It’s real weird. There doesn’t seem to be anything particular about the LUNs it cannot report on.
naviseccli -h 1.1.1.4 lun -list -l 305
Could not retrieve the specified (lun). The (lun) may not exist
thanks
Dave
dynamox
9 Legend
•
20.4K Posts
0
September 26th, 2014 11:00
interesting, same thing if you run naviseccli against the other SP ?
dynamox
9 Legend
•
20.4K Posts
0
September 26th, 2014 12:00
what if you try by the name
lun -list -name "LUN 305"
dynamox
9 Legend
•
20.4K Posts
0
September 26th, 2014 12:00
yep, i see that same thing. How shortsighted of navi developers, so much for consistency.
downhill2
2 Intern
•
157 Posts
0
September 26th, 2014 12:00
Ok, I did discover that the common theme here is the –l lun# only works with luns in a pool. It will not work against a traditional lun. The name option fails too against thick luns. Man, I can’t cipher this out of the CLI manual and I can’t imagine why the functionality wouldn’t work against a non-pool lun, but seems to be the case here.
naviseccli -h 1.1.1.4 lun -list -name "LUN 305>maptst01_fence_0"
Could not retrieve the specified (lun). The (lun) may not exist
That sucks
downhill2
2 Intern
•
157 Posts
0
September 26th, 2014 13:00
Good (well for confirming). Any developers moderating this forum that care to provide a new and improved (working) version of the command?
Even if they do fix it, guess it's back to the drawing board to extract the bits we want.
thanks dynamox
dynamox
9 Legend
•
20.4K Posts
0
September 26th, 2014 13:00
naviseccli is so old, clumsy ..so little changed in years. You will need to get creative and work with what you got. How about dumping output from naviseccli getall, get a list of all LUN by parsing for "LOGICAL UNIT NUMBER" string, then work against that list of LUNs ?
downhill2
2 Intern
•
157 Posts
0
September 29th, 2014 14:00
Yeah, getlun works but it doesn’t have the details I’m looking for to script around. I haven’t used the arayconfig command at all but may look into it. It’s really a drag to know that the lun command has exactly what I need but in our case, fails 50% of the time.
thanks
Dave
kelleg
4.5K Posts
0
September 29th, 2014 14:00
Does the old "getlun" still work for traditional LUNs>
What about the arrayconfig command?
glen
downhill2
2 Intern
•
157 Posts
0
October 7th, 2014 13:00
Yeah, the getlun has most but what I was looking for was the thin provisioning aspects of some luns without having to jump between commands. It would seem to me that the lun command would be ideal if only it worked for all types of luns. The getlun is "getting me by" for now.
thanks Glen