cancel
Showing results for 
Search instead for 
Did you mean: 

VCM Problem

SOLVED
Go to solution
The Brit
Honored Contributor

VCM Problem

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
8 REPLIES
The Brit
Honored Contributor

Re: VCM Problem

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
Honored Contributor

Re: VCM Problem

before good old yank out yank in yuo might try to reset module from OA so the next module starts to run VCM.
Remember to give Kudos to answers! (click the KUDOS star)

You can find me from Twitter @JKytsi
HEM_2
Honored Contributor
Solution

Re: VCM Problem

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
Honored Contributor

Re: VCM Problem

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
Honored Contributor

Re: VCM Problem

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
Honored Contributor

Re: VCM Problem

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
Occasional Advisor

Re: VCM Problem

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
Honored Contributor

Re: VCM Problem

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.