Ahoy there! This is my personal blog which I use as my memory extension and a medium to share stuff that could be useful to others.

VMware Archives

VMware HA Agent Failure

Problem:

When trying to enable HA on an ESXi 4.1 cluster, the following error is displayed:

HAFailure_Mgmt

Also, the Summary tab for the ESXi host on which the HA agent fails shows the following:

HAFailure_Summary

Background & Analysis:

  • The HA agents on ESXi hosts in a cluster use the Management VMkernel ports for communication.
  • If an ESXi host in a cluster has more than one Management VMkernel port, then the HA agent on that host does not know which VMkernel port to use and hence the HA agent fails to work on that host.
  • In some cases, extra Management VMkernel ports are used in different VLANs for more efficient P2V conversions.

 

Solution:

For the ESXi Cluster:

STEP 1: Configure das.allowNetwork0=<Management VMkernel port> in the Advanced Options for VMware HA,

where  <Management VMkernel port> = Name of the VMkernel port used for ESXi Management (default value is “Management Network”

STEP 2: Disable and enable HA

 

Refer this VMware KB Article for more details.

NOTE: With the above solution implemented, ensure that you do not rename the Management VMkernel Port later.

Root Cause:

More than one VMkernel port for ESXi Management caused the HA agent to fail.

 

(1) The solution above describes a successful problem-solving experience and may not be applicable to other problems with similar symptoms.

(2) Your rating of this post will be much appreciated as it gives me and others who read this article, an indication of whether this solution has worked for people other than me. Also, feel free to leave comments.

 

VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Configuring vSphere DRS : An Example

vSphere Distributed Resource Scheduler (DRS) is one of the several features in vSphere that comes very handy for deployments.

Given below are details of how I use vSphere DRS (in a simple configuration) which has worked very well. I could do this given my organization’s standards for application deployment and VM nomenclature. So, this configuration may not be suitable in other scenarios:

Objective: To distribute VMs belonging to an application, across ESXi hosts within a cluster such that the application runs on more than one ESXi host.

Our Standards (Pre-Requisites):

  • Every application runs on more than one VM.
  • All VMs are deployed on ESXi clusters (to use features like DRS).
  • All VMs and ESXi hosts use a nomenclature which includes a 2-digit suffix (starting from 01).

Configuring DRS for ESXi Clusters:

STEP 1: Configure Automation Level and Migration Threshold

At first, we were apprehensive of full automation and an aggressive migration threshold. However, given that we provision adequate capacity (ESXi hosts) and the positive results of vMotion on our critical applications, the following settings have worked well.

 

DRS-Rules-1

STEP 2: Configure DRS Groups

  • All the VMs with odd number suffixes in their names go into the VM-Nodes-Odds group.
  • All the VMs with even number suffixes in their names go into the VM-Nodes-Evens group.
  • All the ESXi hosts with odd number suffixes in their names go into the ESXi-Hosts-Odds group.
  • All the ESXi hosts with even number suffixes in their names go into the ESXi-Hosts-Evens group.

 

DRS-Rules-2

 

 

STEP 3: Configure DRS Rules

Configure Host-Affinity Rules VM-Nodes-Odds –> ESXi-Hosts-Odds  and VM-Nodes-Evens –> ESXi-Hosts-Evens, using the criterion “should run on hosts in group”.

 

DRS-Rules-4 DRS-Rules-3

VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Cannot deploy OVA due to unsupported features

Problem:

When trying to deploy a VMware VM’s OVA file, the deployment fails with the following error:

OVF-unsupported

 

Background & Analysis:

  • A VM’s OVA file is an archive file containing the Open Virtualization Format (OVF) package for a VM. A typical OVA file contains a Manifest file (.mf), an OVF descriptor file (.ovf) and Hard drive images (.vmdk).
  • The error in the screenshot refers to a line in the OVF descriptor file. Line 135 of the OVF descriptor file is given below:
 <rasd:addressonparent>15</rasd:addressonparent> 
  • The above line in the OVF descriptor corresponds to the follow setting for the SCSI controller for one of the Virtual Disks used by the VM:

 

 

OVF-unsupportescictrl15

 

It’s rather strange that a VM can run fine when using SCSI(3:15) controller, but we cannot deploy an OVA/OVF containing this controller.

 

Solution:

In order to resolve this specific error, here’s what I implemented:

 

STEP 1: Extract the OVF package from the OVA file

Use a software such as 7-zip (it’s free) to extract the OVA archive file. Upon successful extraction, you should see the .mf, .ovf and .vmdk files.

 

STEP 2: Modify the OVF descriptor

Modify the erroneous line to reflect the following (basically, just switched to SCSI(3:1) controller for Hard disk 5):

 <rasd:addressonparent>1</rasd:addressonparent> 

NOTE: I used SCSI(3:1) and it worked for me. However, other values may work too, but this problem made it clear that a value such as 15 does not work.

 

STEP 3: Modify the Manifest file

  • The Manifest file (.mf) contains the SHA1 hashes for all the other files in the OVF package.
  • Calculate the SHA1 hash for the modified OVF descriptor (I used SHA1 Generator ) and update the manifest file with the new SHA1 hash.

 

STEP 4: Deploy the OVF

You do not need to re-archive the OVF package into an OVA, because you can simply deploy the OVF package by selecting the OVF descriptor when deploying the OVF via the vSphere client.

 

Root Cause:

Impermissible value for SCSI controller for Virtual Hard Disk in a VMware VM’s OVF descriptor.

 

(1) The solution above describes a successful problem-solving experience and may not be applicable to other problems with similar symptoms.

(2) Your rating of this post will be much appreciated as it gives me and others who read this article, an indication of whether this solution has worked for people other than me. Also, feel free to leave comments.

 

VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Suppress vSphere 5 Heartbeat Datastore warning

Problem:

After configuring HA for a vSphere 5 ESXi cluster, each host in the cluster displays the following error message:

HA-DS-SuppressError

Background & Analysis:

vSphere 5 introduces Datastore heartbeats in addition to network heartbeats for HA, in order to distinguish between a network-isolated host and a crashed host.

Solution:

Using the vSphere client, do the following:

STEP 1: Right-click the ESXi cluster –> Select “Edit Settings” –> Select “vSphere HA” –> Click on “Advanced Options” and enter the following Option – Value:

das.ignoreInsufficientHbDatastore – true  

The default value is false.

 

STEP 2: Right-click the ESXi cluster –> Select “Edit Settings” –> Select “Cluster Features” –> Deselect “Turn on vSphere HA”

 

STEP 3: Right-click the ESXi cluster –> Select “Edit Settings” –> Select “Cluster Features” –> Select “Turn on vSphere HA”

 

Root Cause:

vSphere 5 requires at least 2 datastores (shared) per host in order for Datastore Heartbeats to work. The maximum number of shared datastores allowed for heartbeat is 5.

 

(1) The solution above describes a successful problem-solving experience and may not be applicable to other problems with similar symptoms.

(2) Your rating of this post will be much appreciated as it gives me and others who read this article, an indication of whether this solution has worked for people other than me. Also, feel free to leave comments.

 

VN:F [1.9.22_1171]
Rating: +2 (from 2 votes)