Thanks for the explanation Richard.

It doesn’t look like the vCentre credential brings back the Serial No. of the Blade (or the enclosure).  I don’t think you can see this info within vCentre itself so this would probably explain it?  I guess in this scenario, we would have to discover the ESXi hosts via SSH to bring back the serial no. info and build this relationship.

Mark Lemar - 03 November 2011 11:16 AM

I don’t think you can see this info within vCentre itself so this would probably explain it?

That’s correct, it’s not current available in the API and vCentre uses the same ones to talk to the nodes that we do.

Just to confirm that this pattern worked for me after discovering a blade via WMI. 

We discovered the onboard administrator of the enclosure itself via SNMP which returns the serial no. and creates a network device.  Maybe the Network device and Host Container could be linked on serial no.  Looking to discoery model details of the enclosure if possible.

Also, need to try and do something similar with Sun T6340 Blades and Sun 6000 Blade chassis.

Note that we have a few cases of administration devices being misrecognised as NetworkDevices; clearly they are not really the same as switches or routers so expect in the future these devices to migrate to different nodekinds.

The future proof and robust way of extending data on the HostContainer is to focus on commands run on and during the SSH discovery of the Host nodes within it.

Charles Oldham - 15 November 2011 11:35 AM

Note that we have a few cases of administration devices being misrecognised as NetworkDevices; clearly they are not really the same as switches or routers so expect in the future these devices to migrate to different nodekinds.

The future proof and robust way of extending data on the HostContainer is to focus on commands run on and during the SSH discovery of the Host nodes within it.

Charles, I’m really stuck there :-(
We have ssh access to the blade enclosures and know how to grab loads of information from there. The other methods described here only give us very few information about the enclosure.
They are discovered as Network devices just as you mentioned above. The blade servers themselves run on various OSs and I would really like to access the enclosure directly via ssh. How can I do that? Should I try to execute “ssh blade-enclosure command” from within the ssh session of the blade server?
Thanks
Thomas

Hi.

We would very much also like to extract all Enclosure related information from the enclosure instead of each server since there might be server access problems on occation due to various reasons.

SSH works on enclosures and they have LDAP functionality for accounts.
In the SSH session we can run the cmd “show server names” and it will give us a very nice and simple list to work with.

It will show BAY,Server name, Serial number of server, Status [on/off], Power, UID and partner.

My problem is that I cannot get past the ssh-credential configuration and get in to the actual coding of such a pattern since the SSH-Session never seems to work with this terminal.

The terminal prompt looks like this “enclosure03kst8oa1>” but I have a feeling that there is more to it than just the prompt format.

Is there any way to make this work without building rocket ships to get there?

Best Regards
Roger Candergart

Roger,
What would you say is the Operating System you login to? Is it among the supported operating systems to discover from ADDM?

Petrus, it is not really a supported OS.
It does not even look similar to any Computer OS, it is an HP Hardware SSH-Session.
(HP Enclosure unit) with its own network configuration

I would like to run a discovery.runCommand() on it to be able to use the internal information since this information is not as easy to find in the SNMP-Library and I am not sure wether ADDM supports this device over SNMP either.

Am I limited to the supported operating systems even in own patterns?

Roger,
I think you correctly spotted the problem: You can not set-up an ssh connection and execute a command to the enclosure in this situation.
I circumvented this with the following hack (oh no, Charles will hit me… :-( )
a) On any host (call it host_a), execute a script that collects everything you need by setting up an ssh connection to your enclosure and put the results in a file
b) write a pattern which triggers on host_a. It should read your result file, parse it and build up your model.
c) extend your taxonomy if you wish to model more than the usual stuff
d) write a pattern to sync this to your cmdb (I didn’t do that as we don’t need that information depth in our cmdb)

See the attachment for the result

Hi, Thank you Thomas.

I did almost that.
I did A and B and for the time beeing skipped C and D.

I think that writing an RFE towards BMC might better suit my position as I would like our installation to run as smooth as possible without manual attention to re-applying manual hacks upon future upgrades of our appliances.

I got what I was looking for and it was an answer to if it was possible without building rocketships or not :)

I thank you for your reply.

/Roger Candergart

Hi Richard,

We’ve noticed that this pattern seems to cause an issue when discovering HP Proliant Blades running Windows and Citrix Presenation Server.  When this pattern is activated, it seems to prevent the host from being joined to the Citrix Farm Cluster identified from one of two possible reg keys storing this value.

There’s more info about the issue in the following forum posting I made and I’ve raised ISS03888270 with support about it.

http://discovery.bmc.com/community/forum/viewthread/2237/

I’ve been working with support and pinpointed the problem to happening only when this pattern is activated.  I appreciate that the pattern you supplied isn’t a supported pattern, but I wondered if you might be able to advise on how it’s affecting these hosts from being joined to the Citrix farm cluster?

Many thanks,

Mark