The greatest challenge to any thinker is stating the problem in a way that will allow a solution

Bertrand Russell

Welcome to vBlog, a personal record of my techy tinkerings and particular ponderings.

I tend to focus on VMware virtualisation, and the interaction/automation of it using PowerCLI (VMware's PowerShell Snapin), but anything that I happen to stumble across that seems like it might be of use at a later date, may well get recorded here.

I also maintain vWiki, which was a predecessor to this blog. Wiki's are great for quickly recording snippets of info, but tend not to look that great; Blog's are better looking things, but seem to require more effort so that the posts/articles are accessible in their own right. As a result I tend to update both interchangeably as available time, and depth of thought, permit.

If you happen to find anything of use, or in need of correction please leave a comment. Knowing that my ramblings are of some use is a great reward; and similarly I'd hate to waste anybody's time by feeding them duff info.

See these pages for me info about me, and my vBlog, and below for my recent posts...

3 Apr 2012

VMware

5 comments

With SSH access to your ESX servers, it is relatively easy to get the driver and firmware software revision versions that are running (see further reading section at bottom of post).  Which is fine for a one-off inspection, but if you want review your entire ESX estate, this can be quite tedious.

With the wonder of PowerCLI, it is possible to gain most of this information from your vCentre, which will have sourced the information from your ESX through its hardware CIM provider.  But the quality of data returned in this manner varies, you can get…

  • No data (if you server vendor hasn’t fully implemented CIM to cover the server and peripheral devices, or you haven’t installed the CIM provider software, even if you can get data for X and Y, Z may be missing, for example HBA firmware on all HP servers I’ve had the pleasure of looking after)
  • Duplicate data (if you’ve upgraded software you can sometimes get both old and new versions reported)
  • Inconsistent data (representations vary between manufacturers/vendors, so dealing with different makes or even models from the same manufacturer is problematic)

I do all reporting through PowerShell and PowerCLI scripts, and had got fed up with having to tinker with my scripts to try and never fully trusting the data I was seeing.  But more recently I’ve been using PowerShell to act as an SSH client, so decided to take a different approach…
Continue reading →

The memory sticks in HP blades (as in any server) will occasionally experience errors, more often than not these are recoverable, and are handled without pulling down the software that’s running on it.  However, a tally is kept, so that poorly memory stick can be identified and dealt with.

Non-critical (recoverable) memory errors that have breached an acceptable level generate an error through to the HP Onboard Administrator (OA) as a degraded memory state.  This will be visible as a yellow warning triangle on the OA, will propagate through to your monitoring system (eg SCOM), and through the vCentre Hardware Status for the affected ESX.

Once the problematic memory stick is swapped out, the alert will clear from the OA (and SCOM), but will still be visible through vCentre.  In order to clear down, the server’s System Event Log needs to be reset, and this refreshed through the CIM provider… Continue reading →