Contributor
Contributor

Host is unavailable for checking compliance.

Hey guys, I'm having a little issue with some new ESXi 5.1 hosts I recently stood up.

We have a cluster built in vCenter 5.1 that is made up of 8 hosts. All are Cisco B200 M3s. 4 of which were recently stood up. I am having problems with these new 4 in that they will not fully accept the host profile that is attached to the cluster level for these hosts. The host profile that is built for this cluster is really just to apply the network configuration to new hosts added to this cluster. Unfortunately, for these new hosts it says it has applied this Host Profile but none of the network configurations are being applied and they are being shown as noncompliant with a reason of "Host is unavailable for checking compliance."  Thanks for any assistance.

10 Replies
Enthusiast
Enthusiast

hi there,

sorry but I have no solution for your problem, but we are facing the same...

Did you get any fix for the issue?

Regards,

Harold

0 Kudos
Contributor
Contributor

In my case, the Reference Host for the profile had been misplaced somehow.  A reference host was still listed on the profile's Summary tab, but an error message declared that no reference host was configured for the profile.

This was resolved by selecting

  • Change Reference Host...
  • Update Profile from Reference Host

I don't know what caused this condition.

Regards

Craig J

0 Kudos
Contributor
Contributor

I have the same problem. Two new blades in the cluster, identical with the old ones, identical patch level are "unavailable for checking compliance".

Added two new, identical hosts. Reference Hosts is NOT the problem.

When creating a profile from one of the new hosts, I can check this host for compliance and the old hosts but NOT the second new host.

However, after disabling the storage potion in the profile, checking is possible (sometimes) in vSphere Client and (always) in webclient.

This is quite odd...right now I spent more time messing around with the profiles than they can ever save me compared to manual configuration. Also just to mention: I want to join 18 hosts to the same domain ... have to enter the same username and password 18 times for the answer file. Not very smart...

Quite frustrating experience...

0 Kudos
Contributor
Contributor

Did anyone ever find a solution for this problem?

We're experiencing the same issue with a new host in our 5.5 (1331820) cluster. I've added an new, identical host. What i have tried so far:

- change reference host

- create new profile from other reference host

- manually set every setting that needed to change if the profile would work. (for as far as i can see)

- add the new host to dvswitch

- remove the new host from the dvswitch

- remove and re-add each host from dvswitch

- rebooted every host in the cluster (i'm a windows admin 😉

Only profile that i seem to be able to check compliance with is the profile i made of the new host itself...

while writing this i've found a "solution" that seemed to solve my problem;

- manually do all of the settings on the new host.

- create profile from the new host

- check compliance against new profile

0 Kudos
Contributor
Contributor

I HAVE SOLVED THIS PROBLEM!!!

Theroy:

The Host Profile Compliance Check cannot complete if the VMkernels that exist on each host aren't aligned, (they have to have the same vmk#s).  For instance a host's kernel for management is on vmk1 on one host and the reference host for the host profile has its management kernel on vmk0 (which is written to the host profile) then the first host will be unavailable for compliance checks.  This will be true for ALL VMkernels!!!  vMotion, iSCSI, FTlogging, ...etc.  It was a standard VMkernel that I was using for the Cisco N1kV that got me.  Somehow all but two hosts had a kernel named vmk3 for this while two hosts had vmk2.  I had to make sure they all were the same name, (vmk2), and the compliance check came back normal for all hosts.

Solution:

  • First check all your hosts' VMkernals and record/remember which kernels you are using for what purposes.
  • Develop a standard, (make a plan), for your hosts to conform to.
  • Remove or replace the offending VMkernels.  This may require some crafty shuffling at times.
    • For kernel swapping I suggest adding temporary redundant kernels first. They will be named counting up, filling in any missing numbers, i.e. vmk4, vmk5... Then give them an IP, if needed, on the same subnet.
    • Remove the old kernels so that their names are free for new kernals.
    • Add the kernels back in to the appropriate locations in the order that they need to be named.
    • Now you can remove the temporary kernels.
  • Check the compliance and refresh.

Note: There may be a way to change the vmk# name in PowerCLI but this works and will be easier for most users.

Contributor
Contributor

I resolved this by editing a hostprofile and applying it to the host that is not configured correctly:

  • Network Configuration
    • Host virtual NIC
      • Choose your port group
        • Vmknic name policy
        • changed this to "vmk0" (it was vkm1)
      • Choose your port group
        • Vmknic name policy
        • changed this to "vmk1" (it was vkm0)
0 Kudos
Enthusiast
Enthusiast

Stormarov & dannybeuker. You guys nailed it.

This was due to a vmkernel(s) out of sequential order.

I love finding bugs in host profiles Smiley Happy

Let you guys know I experienced this error at a customer site.

vSphere 5.5 Update 1 build number = 1891313 (vCenter)

Host build = 1746018

0 Kudos
Contributor
Contributor

Thanks, this solved it for me also!

0 Kudos
Contributor
Contributor

In case anyone looks at this thread, find that their vmk interfaces are lined up, but it still gives you the "Host is unavailable for checking compliance" error. The problem occurred for me because I had disabled IPv6 on my reference host, but not the others. Once I disabled IPv6 on the rest of the hosts and reboot them, hosts profiles started working.

0 Kudos
Contributor
Contributor

So I ran into this again. The solution to change the vmk order/numbering is indeed the fix, but in my case, I had a problem actually making this change. Not sure how, but the entire cluster is setup like so :

vmk1     MGMT IP

vmk0     VMOTION IP


It is in that exact order (which has to match for host profiles to be happy). The problem host :


vmk0     MGMT IP

vmk1     VMOTION IP

So, it's not just an order thing, but they are also swapped. I can easily drop vmk1, but I'm left with vmk0 with the management IP. How do you "move it" to vmk1? Edit the esx.conf file. Replace the two "vmk0" entries with "vmk1" and reboot.

Once I had vmk1 as the only one in place with the desired IP, I added vmotion back in. It took the vmk0 slot and was sequentially after vmk1.

Host profiles now works. FYI, vCenter 5.5 3252642, vSphere 5.5 3568722.  It's truly silly.


0 Kudos