Created this pattern to obtain similar functionality to the AIX system P hardware pattern, but for HP Blade Chassis.

All information is obtained from DMIDECODE command, hence requires high priviliges. Using sudo is therefor enabled by default in the configuration part of the pattern.

You may find it useful :)
Cheers!

Edit:If anyone know how this information can be obtained from a Windows system, kindly let me know.

Interesting works as always Petrus :)

It would be really handy if you could post some example output (suitably blanked if needed) with patterns like these so we can understand it as best we can.

By the looks of it you are getting a hardware identifier of the underlying frame, which is good. How stable is the recovery of SerialID? The reason I ask is discovery stability; if it can vary each time you ask the same system then you will find you end up with 2 HostContainers due to your fallback key generation. If it is more that any one particular system will always get it or not then the fallback key generation is more stable. It’s one of those tricky judgement calls in modelling.

As an aside it is our usual best practise to include the type in the key, just in the off chance that another technology uses the same model string and name.

A final thought - can HP Blades be moved between frames? If they can then you may need to double check that your Host is not related to any other HostContianer nodes. Normal style is to check at the start of the pattern and remove the relationships that were not confirmed by the pattern. You don’t need to worry about maintaining the HostContainer nodes as the internal rules will remove it when the last Host is unlinked.

Charles Oldham - 24 May 2010 09:07 AM

By the looks of it you are getting a hardware identifier of the underlying frame, which is good. How stable is the recovery of SerialID? The reason I ask is discovery stability; if it can vary each time you ask the same system then you will find you end up with 2 HostContainers due to your fallback key generation. If it is more that any one particular system will always get it or not then the fallback key generation is more stable. It’s one of those tricky judgement calls in modelling.

From my tests (around 20 various hosts) the serialID is consistent and unique for each Blade.

Charles Oldham - 24 May 2010 09:07 AM

As an aside it is our usual best practise to include the type in the key, just in the off chance that another technology uses the same model string and name.

Will do :)

Charles Oldham - 24 May 2010 09:07 AM

A final thought - can HP Blades be moved between frames? If they can then you may need to double check that your Host is not related to any other HostContianer nodes. Normal style is to check at the start of the pattern and remove the relationships that were not confirmed by the pattern. You don’t need to worry about maintaining the HostContainer nodes as the internal rules will remove it when the last Host is unlinked.

Hmmm… I guess they can :) Didn´t think about that, thanks for the comments.

Blade view

Host view

Updated pattern with various stuff after the feedback from Charles.

Come to think of it… wouldn´t

be more efficient than having the model.destroy function?

uniquerel was designed for these sort of situations so yes a good choice to keep the code cleaner.

When you say “Blade” do you meaan the blade frame/enclosure or the individual blade within it? I think you mean the blade frame as that makes sense from your implementation, but it’s a little confusing. Don’t you just love terminology…

:) haha…
This is indeed the fram/enclosure… In the example screenshots attached the Blade model c7000 can hold X amount of ProLiant BL460c G1 models. I guess uniquerel function prohibits several ProLiant BL460c G1 servers to be linked to the Blade Chassis… so I really shouldn´t think as much as I do ;)

I’ve written a similar pattern to handle Blades. It’s a little more complex, but also supports Windows (and Linux).

It only runs dmidecode once, but does a bunch of awk on it to make sure it actually matches the right serial :)

Just as a disclaimer, I wrote it, but does not mean it’s supported by BMC :) However, do let me know here about issues, changes etc… so we can keep rolling them into the pattern.

Petrus Johansson - 24 May 2010 11:48 AM

so I really shouldn´t think as much as I do ;)

In my experience over thinking is preferable to under thinking ;)

Richard >
From what I can see our patterns model different things, as the query I run in the pattern corresponds to DMI Type 201 (if I remember correctly) not DMI Type 3 as in yours.

DMI Type 3, if I´m not mistaken, is a single chassi dedicated to one server. I assume your pattern returns the same serial number as the hostInfo returns.(?)

During testing (and production) the serial returned is not the HostInfo one. This is the serial of the enclosure that the blade lives in. It’s modelling just fine at a customer site, showing 6 x BL460’s per enclosure. I wrote this a while back, and remember spending ages on the awk to make sure it got the right serial.

I’d be interested to hear how it worked/didn’t at your side, since I only had one environment to test. It did have about 7 different enclosures though, and all worked fine. :)

Richard > GREAT!
Your pattern works (almost) perfect in my environments as well. Tried running it against the same hosts as I verified my own pattern against. Conclusions:

- We identify the same chassis serial number from two different places in dmidecode output, yours from DMI Type 3, and I grab it from DMI Type 207.
- DMI Type 3 does not contain the Chassi name, which is important to us, hence using DMI Type 207 instead.

All in all, the patterns does the same thing in 2 slightly different ways providing more or less the same result.

Will definately try yours out on some windows hosts

I have my pattern running successful for both Linux and Windows host with one minor irritation…
Does anyone know if/where I can get the Model information from a Windows host.

On Linux, the Model information is available from the dmidecode cmd, like: “HP BladeSystem c7000 Enclosure G2”. This information is of great value to my techies, but I have not found a way to obtain this information from Windows.
“Select Model from Win32_SystemEnclosure” does NOT do the trick. This field is blank in all hosts. :(

Hi guys,

I’m new here and this is my first post so go easy on me!

I’m using 8.3 to try and discover some HP C7000 Blade enclosures so I can attempt to identify their relationship to the physical BL460c G6 Blades which they host.  These particular blades are running ESXi 4.0 and I have discovered these using a vCentre credential.

I have discovered one of the Blade enclosures using an SNMP credential and as a result it has dropped in under the ‘Network Devices’ container.  I noticed from your posts and screenshots above that your enclosures are listed under the ‘Host Containers’ container so I’m guessing that you discovered them using a different method?

Any advice would be greatly appreciated.

Cheers,

Mark

Hi Mark, welcome to the forum :)

So we’ve been using SSH / WMI (windows) rather than SNMP. We’re not actually discovering the blade enclosures themselves, but getting the information about them from the actual Blades.

When logged into the OS running on a Blade we query the BIOS of this Blade. This returns both the serial number of the Blade itself, but also the enclosure. Using the enclosure serial number we build a host container, and attach all the blades to that.