I've been using the HiCommand CLIEX (the extended CLI) today. It differs from the normal CLI in that it talks directly to the array via a command device and bypasses both Storage Navigator and Device Manager. HDS have needed this way of communicating with an array for a long time.
On the one hand, CLIEX is a good thing; the functions are more akin to those offered by EMC's Solutions Enabler in that I can perform direct configuration on the array without an intermediate product. Some of the things I've tried include extracting the actual configuration of an array (which can be obtained in XML format) and creating Host Storage Domains and assigning LDEVs. Although the commands aren't lightning quick (no pun intended), they are certainly quicker than the corresponding commands through Device Manager or Storage Navigator and obviously remove the need to install Device Manager in its entirety. As I'm running tests against a new array, I want to create lots of HSDs (one per FEP) and assign a separate LDEV to each. CLIEX saved me a lot of time (especially as I haven't got a Device Manager up yet).
On the negative side, the commands are powerful and "delete" functions give no warning or final check; so at your peril use the delete functions! I checked removing an LDEV while running (a lot) of I/O to a LUN and the command was bounced, however when the I/O was reduced (but the LUN still technically in use), I was able to pull the LDEV away with the obvious consequences. Also, these commands talk directly to the array and appear to bypass the configuration on the SVP. If you make a CLIEX change followed up by a Storage Navigator change without first having refreshed SN, then you simply overwrite the CLIEX changes (I know, I tried it).
One little bugette I found... The CLIEX command hdvmcliex is actually a batch file, so if you want to call the command from within a batch script you need to prefix with the "CALL" command.
I can see the CLIEX interface could be extremely useful. I intend to use it to mass configure a USP from scratch. In addition, I can also see how it could be useful to create dynamic failover scripts (more on this in a future post) without the need for Device Manager to be running. However HDS need to beef up the security around the product to prevent inadvertent allocation and deallocation gotchas. They also need to consider moving the locking mechanism (which allows a reserve to be taken on the SVP and prevent SN/CLIEX/Device Manager clashing configuration changes) to being a specific CLIEX command rather than relying on the Device Manager locking function.
One final thought... I'm not sure of any additional security to prevent any user with a command device from installing and running CLIEX and trashing an entire array. Unless you know otherwise?
Monday 2 July 2007
HiCommand CLIEX
Subscribe to:
Post Comments (Atom)
Posts
3 comments:
Chris,
Although CLIEX is useful, you might like to know that HDvM 5.5 introduced CLI BATCH processing. This is easier to use than CLIEX for such tasks as bulk addition of many LUNs to a storage subsystem. Internal tests have shown that it is faster than CLIEX when more than 20 or so LUNs are being assigned at one time.
It is easy to generate - as the syntax is the same as HDvM CLI. For example, the normal CLI AddLun statements are just surrounded by beginbatch and endbatch statements.
In addition, you can use CLI BATCH against subsystems like 9500V and AMS which do not support CLIEX.
Another advantage of using HDvM CLI is the audit trail that can now be written as standard Windows Events on the HDvM server - which you can easily parse with Log Parser.
Mike Le Voi
Hi Chris,
I was looking at preparing a report for my Array Group utilization. Any clues appreciated.
I'm unable to get this going. One of the syntaxes i created is to find the external DEV number for a list of USP Luns. This was needed for me to unmap these external LDEVs and reformat them on the AMS.
$result = `E:\\Apps\\WeBStorageDB\\DVMCli\\hicommandcli GetStorageArray "subtarget=LDEV" "model=USP" "serialnum=22222" "devnum=$ldev" "ldevsubinfo=VolumeConnection" "ldevfilter=open" | E:\\Apps\\UnxUtils\\grep -w externalDevNum`;
Bijucyborg - what response are you getting from running the command? (BTW apologies for the slow reply, been on vacation)
Post a Comment