Host Profiles are a feature available to those who have acquired the vSphere Enterprise Plus licensing, and is a tool to help provide and maintain a compliant configuration for your hosts, among other reasons that I won’t dig into too deeply here. However, for those who have dipped a toe into the waters of a host profile for the first time might attest, they can be a tad finicky at first blush. With the introduction of vSphere 5, a lot of additional configuration items are tracked by a host profile (including answer files), that can make veterans of the vSphere 4 days a bit frustrated.

In this post, I’ll cover some tricks to get them working the way you want, along with coverage of some common issues you might find with a new host profile. Additionally, I’ll share my process for getting them to work with as little frustration as possible.

A Working Baseline

Whenever I’m working with host profiles, I tend to focus on creating a known working baseline for the reference host – this is the host that you built the host profile from. Doing this before attaching the host profile to any other hosts helps ensure that the profile is free of those “silly configuration” items that tend to crop up when a brand new profile is created. Surprisingly enough, a newly created profile quite often does not even result in compliance on the host it was created from. Confusing, yes? 🙂

So, for this first section, create a new host profile from a reference host and attach it only to the reference host that you created it from. Then, check for compliance with this host. As you can see below, my reference host (esx1) is not compliant with its own profile.

Most of the time, the compliance issues revolve around storage. In my case, this is a USB stick with a device naa value and some iSCSI Adapter IQNs. One thing you’ll typically note on the first creation is the failure “Check answer file for host” (bottom issue). Until you create an answer file for the host, you’re going to see this failure.

The answer file is really only necessary in an Auto Deploy environment, and provides your typical list of configuration answers. You may remember making answer files back in the days of installing Windows servers to allow for unattended setup – the theory here is the same.

One of the easiest ways I know to correct the storage issues is to simply disable checking for these values. Logically, each host will have a different value for the local storage and iSCSI IQN anyway, so we don’t want to bake that into the profile. To disable portions of a profile, right click on the profile and choose “Enable / Disable Profile Configuration…”. I find that this option confuses people because they think it will enable or disable the entire configuration, and not parts of it.

The areas below are the common targets to disable, highlighted in yellow.

Once completed, make sure to rescan the host for compliance. The only issues remaining should be the answer file – you’ll need to right click on the host and choose “Update Answer File…” to get that to go away.

Odd Compliance Failures

Sometimes I see some odd compliance failures appear. Take the example below, where a bunch of of the system level resource pools are showing a compliance failure.

Realistically, I don’t care about these hidden resource pools. I would typically just disable checking for them if they became an issue. I’ve highlighted one in particular that seems to appear more often than not, the “host/user/poolX not found on system”. I’m not 100% sure what causes this, but I can replicate it by logging directly into a host (not vCenter) and then update the host profile. It appears that the act of logging in generates a pool for the user.

Sometimes you just need a good ol’ fashioned facepalm

The other common issue is seeing services show up on the list with an expected value of false or true (depending on the reference host). Be very careful when you see these. I’ve created an example below:

I’ve actually seen it where the host profile decided that the vCenter Agent should be disabled, and when you applied the host profile it cut off communications to the host. If you see these “service X doesn’t meet policy “or “Ruleset X doesn’t match the specification” take the time to edit the host profile and see what values are being specified. In the case of the vCenter Agent issue, I edited the profile and set it to enabled.

Thoughts

I’ve spent a lot of time getting host profiles to work properly in a variety of scenarios. Sometimes it can be a real pain the rear, and requires a sharp eye to notice those little configuration issues that can cause havoc. However, I tend to feel they are worth the effort in a medium or larger environment as they save a ton of configuration time and ensure that you don’t miss anything. Even if you disable a ton of the profile and just use it for specific settings, such as some services or rulesets, it can help ensure you have a stable, consistent environment.

I’m interested in hearing your war stories, tips, or general ninja skills with host profiles!