Skip to content

Grappling With vSphere 5 Host Profiles

by Chris Wahl on Sep 17th, 2012 | 3,524 views
bionic-commando

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!

From → Tech Guides

6 Comments
  1. thenexus6 permalink - Sep 17th, 2012

    I use profiles to auto-deploy our 60-node cluster starting from release of 5.0. Well, sometimes I think I’d better use stateful install and do configuration updates via CLI scripting :)

    Most annoying host profiles problems for me are:

    1) You can’t save custom routes with profiles (so for example you get a problem with storage vmk when trying to reach the target in another subnet)

    2) After “update from reference host” action you lose all passwords in the profile (yep, it’s what they call “feature”) including iSCSI CHAP passwords so the least painful solution is to forget about updating from ref host right after main configuration is complete and use “edit profile” feature only.

    As a bonus I’ve got a frozen host after trying to boot 5.1 with 5.0 profile (yep, some kernel modules defaults had changed so had to skip this part).

    Anyway, it’s better than nothing and if you’re ready to adapt your infrastructure to fit host profiles restrictions – they allow you to mess hard once (in a free time) and then stay calm if any configuration problem appears.

  2. Craig M permalink - Sep 17th, 2012

    I love host profiles and don’t mind spending the time to nut out these little issues (I’ve come across all of the above) for an initial setup.

    But the 1 thing that does my head in, is every time you update the reference host, you have to go through the same rigmarole again. For some reason the changes I make to the Profile Configuration do not stick after an update.

    That’s my facepalm moment.

    • Chris Wahl permalink - Sep 18th, 2012

      Very true. It would be nice if at least the enable/disable configuration options would stay checked.

  3. Preetam permalink - Dec 15th, 2012

    Great Blog, Not sure how I missed it from my list. Thank you for sharing these valuable lessons

  4. Alex permalink - Dec 18th, 2012

    For the iSCSI Adapter IQN compliance failure message, the iSCSI Adapter IQN is something that’s saved in the Answer File, so it might work better to try doing the Update Answer File action before disabling the iSCSI stuff.

    Some of the other problems raised in this blog post and comments have been improved upon in vSphere 5.1. The enable/disable configuration options should be preserved across the “update from reference host” action, as are admin passwords, local users, and permissions (but maybe not iSCSI CHAP?).

    The set of resource pools managed by host profiles has been limited a lot, and some of the kinks have been worked out around firewall and service configuration.

    Static routes are supported in 5.1 as well.

    PSA and NMP configuration still isn’t going to work well unless the storage hardware is 100% identical, but it should deal with local SAS disks better in 5.1.

Trackbacks & Pingbacks

  1. Some Tips for Host Profiles | VMware Support Insider - VMware Blogs

Leave a Reply

Note: XHTML is allowed. Your email address will never be published.

Subscribe to this comment feed via RSS