When creating new version 5.0 Host Profiles you may quickly find yourself looking at a compliance failure error stating:
Expected user input parameters missing. Check answer file for host.
This error relates to a new feature introduced to Host Profiles with vSphere 5.0, Answer Files.
Answer Files are designed to allow administrators to pre-configure answers to the questions required by deployment via host profiles. For example host specific IP address details.
The vSphere 5 Documentation Center provides specific details related to configuration of Answer Files.
To quickly resolve the Host Profile compliance failure you should right click the host and select ‘Update answer file’.
You will then be prompted to enter the host specific details required for the Host Profile. It will not apply the host profile or cause any change to occur to the host.
Finally run the Host Profile compliance check again to check for any other failures.
Creating new Host Profiles recently I found vSphere 5.0 introduced a number of new settings and I ran into a few that caused failures for compliance checks against various hosts in the cluster.
The high level process I followed was:
- Created a new Host Profile based on first host in the cluster
- Attached second host in the cluster
- Ran Check Compliance
- First error states ‘Option Misc.HeartbeatPanicTimeout doesn’t match the specified criteria’
Checking the Host Profile configuration this setting is found under “Advanced configuration option” and in this case was set to 60.
This setting is described in the VMware article ‘Advanced configuration options for VMware High Availability in vSphere 5.x’ (http://kb.vmware.com/kb/2033250):
My interpretation of this information is that in an HA enabled cluster all hosts will have a Misc.HeartbeatPanicTimeout setting of 60 seconds assuming a default configuration. Checking the host I found the setting was 14.
After further digging I found hosts that had been upgraded from ESXi 4.1 to 5.0 had a setting of 60 while hosts build as ESXi 5.0 had a setting of 14.
Best practice would dictate using the latest standard of 14 however there is a lack of documentation (I could find very little) regarding this and therefore there may be confusion.
I expect a number of admins would find themselves in this position of mixed settings as it would be fairly common to upgrade existing hosts in a cluster and add new hosts at the new version.