VCM Problem

[The Brit]

I have c7000 with VC ENet modules in Bays 1,2,3 & 4. Firmware is at 2.10. (OA at 2.51)

The active VC module is currently unresponsive.

If I use my browser to go directly to the VC Module IP address, I was getting the login screen with the "appication is loading" bar twirling away endlessly. Now I am getting nothing.

If I go to the Virtual Connect Manager from the navigation panel in the OA, I get nothing,

If I try telnet directly from the network, I get "Connection refused by host."

If I use SSH, I do actually get logged in,

Last login: Mon Aug 31 14:59:59 2009 from 10.30.10.102
-------------------------------------------------------------------------------
HP Virtual Connect Management CLI v2.10
(C) Copyright 2006-2009 Hewlett-Packard Development Company, L.P.
All Rights Reserved
-------------------------------------------------------------------------------

however the terminal is effectively hung.

Any Suggestions (short of pulling the VC module)

Dave

[The Brit]

Further,

Does not seem to be affecting any of the servers installed in the enclosure, and running through this/these modules.

So not an immediate, critical issue.

Dave.

[JKytsi]

before good old yank out yank in yuo might try to reset module from OA so the next module starts to run VCM.

[HEM_2 · Accepted solution]

you can try using Virtual Connect Support Utility...

Usage:
vcutil -a resetvcm -i -u -p -b

IP = IP Address of the active Onboard Administrator in enclosure

USER = Name of the Onboard Administrator user with privileges to
access all enclosure interconnect bays

PWD = Password of the Onboard Administrator user
Use * to prompt for password

BAY = The bay number of the target module.

Example:
vcutil -a resetvcm -i 192.168.1.100 -u Administrator -p password -b 1

[WFHC-WI]

Hi Dave,

If you are able to connect to another Virtual Connect module you can use the:

>>reset vcm

command to attempt resetting the management service without bouncing the module.

This command is available via SSH or if you telnet to the enclosure OA and use

>>connect interconnect 2 (for instance.)

Also, outside of re-seating the module you can reboot it via the OA GUI or CLI:
>>restart interconnect 1
This however will cause a brief interruption in service.

good luck

[The Brit]

Thank you for your suggestions guys. I am not experiencing any production problems at the moment, and so I am going to wait until the weekend to force the failover.

(I need to check the NIC teaming on some of our linux blades, they dont like the 30 sec wait that it takes for the VC modules to fail over.)

thanks again

Dave.

[The Brit]

Just and update.

A software RESET the module from the OA, and the problem was resolved. Note the failover was somewhat slower than normal, (about 1 minute)

thanks for your help

Dave.

[J.Jeckl]

Hi at all,

same problem here.
My question now: If I try the RESET button in OA, this will be interrupt the serverblades?
Inside the enclosure runs a lot of clustered systems, but they are all very hard monitored...

Regards JJ

[The Brit]

Hi JJ,
The answer depends on whether your VC modules are redundent, and whether you have your NIC teaming set up correctly.

When you reset the VC module from the OA, this will cause a VC Manager failover. If the Server NIC teaming is set up correctly, the server network traffic will immediately switch to the other VC module, and will normally not cause any problems.

If you dont have you teaming set up, then the VC manager failover will cause an interuption of (usually) ~25-30 secs, although as I mentioned above, when I did it, it took ~ 1min. So it depends on whether your clusters can weather a 1 min interuption (If these are OpenVMS clusters, look at the SYSGEN parameter, RECNXINTERVAL)

Just a suggestion. You should really have started a new thread to get an answer to this. I doubt if anyone else will read this since the thread is closed. I only got it because it was originally my thread.

regards

Dave.