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...

12 Mar 2012

VMware

(No comments)

Whilst not always recommended for production use, its certainly very common for admins to want to have SSH access enabled to all ESX’s all of the time. You don’t need it for day to day support tasks, but it can be very useful, especially when things start to go wrong.  And to my mind, the easier it is to start getting into the detail of an incident, all the better chances you have of resolving it quickly and correctly.

However, enabling SSH access causes a yellow warning on your ESX’s with is annoying, and risks clouding other more important errors you might want to take action on.

If you’re running ESX5 you may see…

  • ESXi Shell for the Host has been enabled
  • SSH for the host has been enabled

There are three ways that I’m aware of to remove the warning… 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 →