topic Re: VCM Problem in BladeSystem - General

VCM Problem

The Brit — Mon, 31 Aug 2009 13:23:46 GMT

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

Re: VCM Problem

The Brit — Mon, 31 Aug 2009 13:31:02 GMT

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.

Re: VCM Problem

JKytsi — Mon, 31 Aug 2009 13:34:25 GMT

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

Re: VCM Problem

HEM_2 — Mon, 31 Aug 2009 13:57:13 GMT

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

Re: VCM Problem

WFHC-WI — Mon, 31 Aug 2009 18:02:22 GMT

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

Re: VCM Problem

The Brit — Tue, 01 Sep 2009 11:43:37 GMT

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.

Re: VCM Problem

The Brit — Thu, 10 Sep 2009 11:25:09 GMT

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.

Re: VCM Problem

J.Jeckl — Mon, 25 Jan 2010 10:07:46 GMT

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

Re: VCM Problem

The Brit — Mon, 25 Jan 2010 12:02:16 GMT

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.