Host Profile Configuration – Answer Files

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.

Host Profile Configuration – Misc.HeartbeatPanicTimeout

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:

  1. Created a new Host Profile based on first host in the cluster
  2. Attached second host in the cluster
  3. Ran Check Compliance
  4. 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):

heartbeat

heartbeat

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.

 

Virtual Machine MAC Addresses

While attending a vSphere  Design Workshop a question arose regarding when a virtual machine MAC address may be changed. It was suggested that a virtual machine’s MAC address should not ever change following initial creation of the VM. However, there appear to be some circumstances under which a virtual machine may be configured with a new MAC address. Some are obvious such as when a new network adapter is added it will have a new MAC address. Others are not as obvious.

In vSphere 5.x performing a vmotion or storage vmotion does not result in a change to the MAC address of a running VM however the documentation suggests that moving a virtual machine location on the same host may result in a network interfaces MAC address changing. The vSphere Documentation Center for 5.0 states:

After the MAC address has been generated, it does not change unless the virtual machine is moved to a different location, for example, to a different path on the same server. The MAC address in the configuration file of the virtual machine is saved. All MAC addresses that have been assigned to network adapters of running and suspended virtual machines on a given physical machine are tracked.

In addition vSphere 5.x does not track the MAC addresses assigned to virtual machines that are powered off. Therefore when a powered off virtual machine is powered on it is possible that it’s MAC address will have been assigned to another virtual machine. In this situation the virtual machine being powered on will be assigned a new MAC address. The vSphere Documentation Center for 5.0 states:

The MAC address of a powered off virtual machine is not checked against those of running or suspended virtual machines. It is possible that when a virtual machine is powered on again, it can acquire a different MAC address. This acquisition is caused by a conflict with a virtual machine that was powered on when this virtual machine was powered off.

Usually MAC addresses are not of great concern to a vSphere administrator. However some software requires a static consistent MAC address. In these cases it is possible to manually configured the MAC address so that it is known and unlikely to change.

A manual MAC address may be configured via the vSphere client:

1. Log in to the vSphere Client and select the virtual machine from the inventory panel.

2. Click the Summary tab and click Edit Settings.

3. Select the network adapter from the Hardware list.

4. In the MAC Address group, select Manual.

5. Enter the static MAC address, and click OK.

For vSphere 5.1 there are some specific requirements that have been helpfully documented by Cormac Hogan in his article ‘Heads Up! Valid Static Address Ranges in vSphere 5.1‘. These requirements appear to have been relaxed in vSphere 5.5 as the vSphere 5.5 Documentation Center states:

…all unique manually generated addresses are supported.