Double-Check the HCL

Joshua Townsend — Thu, 12 Mar 2009 15:57:18 +0000

I wrote some time back about networking problems with a clean install of ESX 3.5 U3 on a HP DL380 G3 server in a lab environment. A simple downgrade to ESX 3.5 RTM corrected the issue and I didn’t think much about it. One of the servers in the lab died and I went about the business of rebuilding it. Having learned my lesson, I started with an ESX 3.5 RTM install and then patched to Update 3 plus other applicable updates. Much to my chagrin, the server began crapping out on me randomly. Some reboots, some networking issues, and other assorted not so good things. Now the DL380 G3 is not the spring chicken it used to be, so I assumed some faulty hardware was probably to blame. Some diagnostics and log reviews yielded no hardware issues.

On a whim, I decided to check the VMware HCL to see if the DL380 G3 was still on the list of compatible servers for ESX. Now, I had checked, or rather ‘remembered’ checking, the HCL before that first problematic install, but a recheck never hurts. When I arrived at the VMware HCL page I saw the same old trusty PDF link with a slightly newer revision date than my previous visit. I was pleasantly surprised when I clicked the PDF link to find that I was redirected to a searchable, filterable forms-based version of the HCL. Nice! Let’s do this thing….

I’m a little lazy, so I simply used a keyword search to look up ‘DL380 G3′. Presto-chango: I’ve got results, and I like what I see:

Search Results for DL380 G3 on the VMware HCL

My eyes jump right to ESX 3.5 – Supported, on my platform, no further questions your honor. Close the old browser window and move on with my life, my life being troubleshooting this darn server.

A few hours later I am still struggling with the server and turn to Ebay for salvation. “If you can’t beat em, cheat em,” my grandfather used to say. I’ll find new hardware for my lab. I identified some other hunk of junk that just might work and decided to check the HCL for it. That’s when it jumped out at me: there are Update versions included in the HCL and I had been to quick to see it on my DL380 G3 search. Back to the HCL.

This time I just do a search for ‘DL380′, leaving off the Generational notation and get the following:

Search Results for DL380 from the VMware HCL

The ProLiant DL380 G5 with Quad-core Intel Xeon processors lists ESX 3.5 U3, ESX 3.5 U2, and ESX 3.5 U1 as supported releases, along with the RTM ESX 3.5. The Update versions are not listed for the G3 or G4. After some self-deprecating curses and a reinstall of ESX 3.5 Update-nada, stability returned.

The lesson learned, double-check the HCL (or if you are a little slow like me, a triple-check doesn’t hurt). The HCL is major version and Update-revision sensitive. And, not all models are treated equally. You’ll notice in the picture to the left that the DL380 G5 has different supported releases depending on the CPU Model.

Also, keep in mind that you need to verify that all components of your VMware infrastructure are on the HCL from Servers and Systems to IO Devices, and Storage/SAN. The VMware HCL site offers some basic tips for searching here: http://www.vmware.com/resources/compatibility/help.php.

Here’s the real take-away: The VMware HCL is there for a reason. Sure, you might be able to get something that is not on the HCL to work, but you may experience instability along the way. In the event that you are running a non-HCL system you may also find that VMware Support may be limited in what they can do for you.

DL380 BIOS Configuration for VMware One more post to wrap up the nonsense with my...
Networking Problems with ESX 3.5 Update 3 on the DL380 G3 I began building up a new lab environment with a...
IBM DS3300 iSCSI Write Performance Solved I have been pulling my hair out with a small...

Securing Your Virtual Infrastructure

Joshua Townsend — Tue, 27 Jan 2009 21:03:38 +0000

Between budget cuts and New Year’s resolutions, improving your security posture is probably near the top of your to-do list. Much has been made of security concerns in a virtual environment, but it is always good to re-visit your configurations and make sure they are still on par with recommended best practices. I began re-reviewing VI security best practices after reading at post by Bob Plankers at The Lone SysAdmin (Bob has been on my reading list for years – he has a great style and always brings fresh insights) on why you would want a second super-user account on your ESX servers.

We certainly all have our own opinions and operations procedures when it comes to configuring and hardening our environments, but I decided to take a look at what the experts had to say on this particular subject and other basic build and hardening recommendations. Here is what I found:

VMware Security Resources

VMware Security Utilities

VI3.5 Security Hardening Whitepaper

Defense Informaion Systems Agency (DISA) ESX Server Security Technical Implementation Guide

DISA ESX Server Checklist

As a side note, DISA publishes many STIG’s at http://iase.disa.mil/stigs/. Your tax dollars paid for these, so you might as well check them out.

NSA VMware ESX Server 3 Configuration Guide

There are also numerous tips and scripts for locking down your virtual infrastructure in the VMware Community Forums (Start here: http://communities.vmware.com/message/941372).

So back to the question of second super user accounts: It seems that best practices are to create a second user account with sufficient access to the console, granting that user SUDO privledges, and then disabling the default root account.

Virtual Infrastructure Client Opens Off Screen A user reported an issue with one of the VM’s...
Upgrading Virtual Hardware in a VMware Virtual Machine May Cause Disks to go Offline I recently posted an article on how specific actions during...
Microsoft Offline Virtual Machine Servicing Tool v2 Released The Microsoft Offline Virtual Machine Servicing Tool v2 could be...

VMtoday » best practices

Double-Check the HCL

Securing Your Virtual Infrastructure