cpqlocfg hung

[Daniel Wong_5]

I use the following command at cmd:
cpqlocfg -s 10.123.123.123 -f gu_2.xml -l o.txt -u admin -p password

The syntex is correct as I've used it on many other server. After it was started, it just hung at "Connecting to Server.." and the output file has one line.

IP Address is: 10.123.123.123

Does anyone experience the same issue? I also wonder if this tool has hidden switches where you can enter a timeout.

Thanks in advance!


*** For Q&A purposese, ip address, userid and password are not real.

[James Hughes_2]

Daniel-
Are you able to ping this iLO? It sounds as if your iLO is not accessible from your client.

There is no hidden switches in cpqlocfg.

James.

[Daniel Wong_5]

The ilo ip is pingable.

I wrote a qb program to go through 400 and soon will be 700 server ilos. The program reads from a txt file for server ip addresses. First it goes through a routine to ensure each ip is pingable then connect to ilo with cpqlocfg.

For some reason, it always hung at the same ip.

I just hoping that there might be some timeout switch for the tool.

Thanks,

[acartes]

Daniel,
I'll submit feedback, but I am not optimistic about this making it in anytime soon.

We've seen similar behavior when CPQLOCFG is pointed at an invalid IP address or to a host that does not reply. The utility tries to open an SSL connection with the host:443, and the timeout (or lack thereof) seems to happen then.

Also check that the SSL port for the web server has not been altered on your troublesome board. CPQLOCFG can take the port number as an argument.

Tip:
When you use CPQLOCFG iteratively with a bunch of iLOs, each script can take awhile to run, particularly when you have 400 or 700 iLOs to hit. You can put the commands in a batch file, and this helps some, but the process is still linear: one iLO after another, and if there is a hiccup, you are in trouble.

A faster way is for the batch file to spawn a bunch of other command windows, each can contact an iLO on its own. And because the process is in parallel, it goes faster. For example, instead of this:

REM Windows firmware update batch file
cpqlocfg -s 192.168.1.1 -f flash.xml
cpqlocfg -s 192.168.1.2 -f flash.xml
cpqlocfg -s 192.168.1.3 -f flash.xml
cpqlocfg -s 192.168.1.4 -f flash.xml
cpqlocfg -s 192.168.1.5 -f flash.xml
cpqlocfg -s 192.168.1.6 -f flash.xml
cpqlocfg -s 192.168.1.7 -f flash.xml
cpqlocfg -s 192.168.1.8 -f flash.xml

you could script it like this:
start cpqlocfg -s 192.168.1.1 -f flash.xml
start cpqlocfg -s 192.168.1.2 -f flash.xml
start cpqlocfg -s 192.168.1.3 -f flash.xml
start cpqlocfg -s 192.168.1.4 -f flash.xml
start cpqlocfg -s 192.168.1.5 -f flash.xml
...
you get the idea

But an advantage would be that the instance that gets hung will not cripple all the other instances. It will be a single command-window that does not close when it completes. And that will draw attention to a problem node.

Keep in mind that there is some limit to how many simultaneous command prompts you can spawn realistically. You'll have to experiment to determine that.

[Daniel Wong_5]

I don't think I got the support I needed from HP and the proposed suggestion is OK but not great simply because...

1. issued submitted but no ETA for when it will be fixed = brushing me off

2. with "start", there are other things to consider (like you've mentioned) such as...

a. how to control the number of processes
b. if divided into serveral machines = more management overhead

I apologize if you do not represent HP, this is HP's fault!