Yellow Bricks

by Duncan Epping

ha

Release notes VC U3

· ·

There seems to be an incorrect advanced option in VC U3.

HA network compliance check
During the configuration of HA in VirtualCenter 2.5 Update 2, the Task & Events tabs might display the following error message and recommendation:
HA agent on <esxhostname> in cluster <clustername> in <datacenter> has an error Incompatible HA Network:
Consider using the Advanced Cluster Settings das.allowNetwork to control network usage.
Starting with VirtualCenter 2.5 Update 2, HA has an enhanced network compliance check to increase cluster reliability. This enhanced network compliance check helps to ensure correct cluster-wide heartbeat network paths. VirtualCenter 2.5 Update 3 allows you to bypass this check to prevent HA configuration problems. To bypass the check, add das.bypassNetworkVerification=yes to the HA advanced settings.

The described option should actually be “das.bypassNetCompatCheck with the values  “true” or “false. So keep this in mind!!!

Update: HA Advanced Options

· ·

A while back I wrote down all the HA advanced options. With VirtualCenter 2.5 Update 3(and the ESX patch that came with it) VMware added another extra advanced options, this is the complete list:

  • das.failuredetectiontime – Amount of milliseconds, timeout time for isolation response action(with a default of 15000 milliseconds).
  • das.isolationaddress[x] – IP adres the ESX hosts uses for it’s heartbeat, where [x] = 0-9. It will use the default gateway by default.
  • das.usedefaultisolationaddress – Value can be true or false and needs to be set in case the default gateway, which is the default isolation address shouldn’t be used for this purpose.
  • das.poweroffonisolation – Values are False or True, this is for setting the isolation response. Default a VM will be powered off.
  • das.vmMemoryMinMB – Higher values will reserve more space for failovers.
  • das.vmCpuMinMHz – Higher values will reserve more space for failovers.
  • das.defaultfailoverhost – Value is a hostname, this host will be the primary failover host.
  • das.failuredetectioninterval – Changes the heartbeat interval among HA hosts. By default, this occurs every second (1000 milliseconds).
  • das.allowVmotionNetworks – Allows a NIC that is used for VMotion networks to be
  • considered for VMware HA usage. This permits a host to have only one NIC configured for management and VMotion combined.
  • das.allowNetwork[x] – Enables the use of port group names to control the networks used for VMware HA, where [x] = 0 – ?. You can set the value to be ʺService Console 2ʺ or ʺManagement Networkʺ to use (only) the networks associated with those port group names in the networking configuration.
  • das.isolationShutdownTimeout – Shutdown time out for the isolation response “Shutdown VM”, default is 300 seconds. In other words, if a VM isn’t shutdown clean when isolation response occured it’s being powered off after 300 seconds.
  • das.bypassNetCompatCheck – Disable the “compatible network” check for HA that was introducedwith Update 2. Default value is “false”, setting it to “true” disables the check.Virtual Machine Monitoring HA advanced options
  • das.failureInterval = The polling interval for failures. Default value is 30.
  • das.maxFailureWindows = Minimum amount of seconds between failure. Default value is 3600 seconds, if VM fails within 3600 seconds VM HA doesn’t restart the machine.
  • das.maxFailures = Maximum amount of VM failures, if the amount is reached VM HA doesn’t restart the machine automatically. Default value is 3.
  • das.minUptime = The minimum uptime in seconds before VM HA starts polling. The default value is 120 seconds.

VirtualCenter 2.5 Update 3 and HA networks

· ·

I wrote about a new patch for ESX(i) 3.5 yesterday and the fact that VirtualCenter 3.5 Update 3 was mentioned. Well today VirtualCenter 2.5 Update 3 has been released! You can pick it up here.

I think the most important fixes are the ones for HA. With Update 2 VM started checking the subnets of the heartbeat network for HA. If these weren’t compatible than HA bailed out. With Update 3 a new advanced option has been introduced ,”das.bypassNetworkVerification”. When this setting is set to “true” the Network compatibility check isn’t done and thus it’s possible to have an incompatible but routable HA heartbeat network.

Another important one is that as of U3 it’s possible again to delete HA advanced options, this problem was introduced in U2 and has been fixed.

An error that was also much talked about on the VMTN forum was the fact that VM’s weren’t vmotioned when maintenance mode was entered even if the admision control was disabled. This error has also been fixed.

These are three most important fixes in U3 in my opinion. Be sure to update and read the release notes for more info and fixes. Please not that the plugins for Update Manager and Converter has also been updated.

Marathon HA/FT vs VMware HA/FT

· ·

A couple of days ago I linked to Mike D. response to Marathon’s blogs. Mike has updated his original blog article and added a second article which responds to another blog by Marathon. Those who are interested in the difference between Marathon’s and VMware’s products should definitely read it. Especially if you’ve only read the Marathon posts so far. Mike D. sets the record straight!

Marathon FT and VMware FT

a short outtake: “This wasn’t talked about but Marathon’s virtualization FT only works with Windows 2003 Standard or Enterprise SP1 today. VMware FT works with any of the over 70 certified guest operating systems that run on Virtual Infrastructure. The Marathon solution also sits deeply embedded within the OS.”

Marathon everRun vs VMware HA – Another Mess

a short outtake: “As you can now see, Marathon obviously has never touched a VMware host to setup VMware HA. They simply type what they want customers to hear on their webpages time and time again and rely on that FUD to get them sales.”

Weird problems with enabling HA on ESXi

· ·

A couple of days ago an ex-colleague phoned me about a weird problem with enabling HA in a ESXi cluster. The following errors occurred:

  1. Configuration of host IP address is inconsistent on host : address resolved to Host misconfigured. IP address of not found on local interfaces
  2. cmd addnode failed for primary node: Internal AAM Error – agent could not start

So the first error(1.) was reported by esxhost01 and the second(2.) by esxhost02.

Let’s start with esxhost01.

So this customer had a VMotion and Management portgroup on two seperate vSwitches. This error seems to indicate that during the configuration HA is using the VMotion portgroup. These hosts have been added to VC with the management portgroup IP(IP+Name also in dns). So how do I make sure that HA isn’t using the VMotion network for HA, it’s easy go to your cluster and open up the advanced options for HA and add the following key with the value false:

  • das.allowVmotionNetworks=false

In other words, don’t use the VMotion network for the HA heartbeat. The weird thing in this case is that it shouldn’t use the VMotion network by default so there seems to be a glitch here…

So now for the second problem.

The HA(AAM) agent could not start. So just to make sure that the USB key wasn’t corrupt the key was recreated. But still this error occurred. As some of you might now, that if you want to use HA with a disk less server you will need to create a userworld swap on the SAN. (Read this KB for more info on that one…) So just to make sure that the swap wasn’t causing this problem the directory was cleaned out and and HA was reconfigured. When the directory was emptied the HA agent installed without any problem at all…

  • When reinstalling ESXi or when strange HA errors occur clean up the userworld swap!

Thanks goes out to Remco for providing me with the additional details!