ILO3 VirtualMedia java socket exception

[Nada O'Neal]

I have 5 new identical BL 460 G7 blades with the ILO3 management software. They're all identical as far as hardware, firmware version, etc. 2 of these are in chassis A, the other three are in chassis B. I'm currently at the stage of doing OS installs. I'm using an ssh tunnel to connect, with ports 23, 80, 443, 3389, 3002, 17988, 17990 redirecting. I'm connecting using the java console rather than the .net console.

For one of the blades in chassis A and one in chassis B, I can connect the virtual media just fine. For the other three blades, the media never seems to connect. When I close the console, the error message appears: "Network Error (java.net.SocketException: socket closed)". 

So at first I thought, surely the issue is the port redirects through the ssh tunnel. Clearly I made typos 3/5 times. But I've checked and re-checked - the ssh tunneling definitions are perfect. 

I tried switching the Virtual Media port from 17988 to 3002, since 3002 is not in use but was open anyway. I get the same socket exception.

I tried switching the Virtual Media port from 17988 to 17677 - what happens when I use a port that's definitely blocked? Now I get a different error - "Network Error (java.net.ConnectException: Connection Refused: connect)". So I don't think the issue is with the ssh tunnel. 

Btw, I connect to one blade at a time - set up ssh tunnel, connect to blade1, close ssh tunnel, make new ssh tunnel, connect to blade 2. I have even tried restarting my computer in-between connecting to these different consoles, in case something-or-other wasn't letting go of something-or-other, and there was some kind of conflict.

Does anyone have any ideas of what I should try next? It's sort of interesting that one blade works in each chassis, and I wonder whether or not that's a coincidence. These blades are the first G7s in these chasses - the rest are G6s. 

[Naj]

Hi,
Are these 2 node (A and B) connected to same VC?
Seems like the issue with VC and you may check the configuration there. i just guess but you may confirm this.

Thanks

BR
Naj

[Nada O'Neal]

Hi Naj,

Thanks for your reply. I was using A and B to designate two different chassis; the five blades are distributed among them. So if the blades are e.g. A1, A2, A3, B1, B2, it's like A2 and B2 are working, and A1, A3, B1 are not working.

I don't currently have access to the hardware setup, but I think it's extremely unlikely that two different chassis/enclosures are sharing a VC - isn't it? (I'm a little confused by your question, because I thought "node" usually refered to a blade or component of the blade, but I think you're using "node" to mean the enclosure.) I'm fairly sure that the two chassis are not on the same VC, and so also the two working nodes are not on the same VC. 

I am curious though why you think it's a VC problem. Is there any documentation you could point me to? Can you give me more details about what you think has gone wrong or what configuration changes are necessary to fix it?

[Jimmy Vance]

Can you VNC or RDP to a system on the same network and make sure everything is working as it should without tossing ssh tunnels into the mix?

[Nada O'Neal]

Thanks, Jimmy Vance. I've put in a request to either get VPN access myself, or have a local person test this for me. You're absolutely right that it's worth testing in the simplest possible case, to eliminate variables.

Also inspired by Naj's suggestions I've put in a request to try one of the non-functioning blades in a newer chassis with a newer VC. It occurs to me that there might be outdated firmware on the older VCs, though I think that the firmware was systematically updated earlier this year. I've requested the firmware version too.

While I'm waiting for these requests to be filled, does anyone have any other suggestions? Also, can anyone flesh out Naj's remarks that it might be the VC a little bit more? Has anyone seen anything similar in the past, and can they refer me to any documentation?

Thanks very much for your kind attention, everyone.

[Jimmy Vance]

The OA and iLO don't connect directly to VC, so I doubt that has any bearing on the issue

[Nada O'Neal]

Yes Jimmy, you are right! I was confused by Naj's message and now I understand that it really can't be the VC. The iLO ports go through the OA, of course. Theoretically it could be old OA firmware that's causing the issue, though again I think that was updated fairly recently. Regardless I'm still asking central IT to try moving one of the malefactors to a more recent chassis.

I am still waiting on either hearing back from someone who tried connecting via the VPN, or getting VPN access myself. Again I don't think that's very likely to be the main issue but it could indirectly be causing the problem, e.g. if the bottleneck caused by the tunnel is making time-outs more likely.

If anyone can think of anything else to try, please let me know... 

[Nada O'Neal]

I just got confirmation that we're using OA version 3.21 - so not the most recent, which is 3.30, but still supposedly OK to work with G7 blades.

[hoffmann_s]

We also had such problems with our first G7  and ILO3 v1.20 and v1.25.

After 2 Days talking to HP Support  we downgraded ILO to v1.16.  Now everything is working fine...

Maybe one next step to try...

Cheers

Sven

[Nada O'Neal]

Thanks Sven! That's very interesting, though slightly terrible. :) I don't have the ability here to downgrade the ILO, but that might be useful for someone else.

I was able to get central IT to upgrade the OA to 3.30, which did not fix the problem with ILO3 v1.20... but maybe it would have if I were able to downgrade the ILO.