thanks.

I would like to see a similar post of how the upcoming VMware FT will react to these failures and isolations as well. Though all I can find about that is a small post and a nice video at http://www.virtualizationteam.com/virtualization-vmware/vmware-esx-40-ft-fault-tolerant-sneak-peek.html
A better post of how FT will act toward these type of failures will be a hit.

Enjoy,
Virtualization Master

Two Servers with ESX 3.5 Update1, I have created a Virtual Switch with those two
1) VMKernel port for VMotion (reverse calble between servers)
2) Service Console 2

Put everything in the DNS and everything seems to work OK. I known that I cannot access the console on that switch, but just in case someone unplug the service console 1 network cable, HA will not transfer all VMs to the second server

If I’m understanding your setup correctly, the big problem I see is that you have only a single uplink for your Service Console connection. If that connection goes down, you’ll trigger isolation response. Depending upon what version of ESX you’re running, isolation response may be set to power down all VMs.

If it were me, I’d combine the Service Console port with the VMotion traffic (unless you have a requirement of a physically segregated VMotion network) and use NIC failover ordering to prioritize the NICs between the two port groups. This provides failover while minimizing the number of NICs required.

If you do have a requirement for a physically segregated VMotion network, then there’s a setting in recent versions of ESX that allows VMware HA to leverage the VMkernel ports for heartbeats as well. That would be an option to explore. Check out Duncan Epping’s site (http://www.yellow-bricks.com) for more information on that setting.

Hope this helps!

I have 5 hosts, each with 2 nics for a total of 4 ports. am using a port on each nic for a total of 2 ports as a virtual switch to which I connect all my vm’s.

I have another virtual switch that contains my virtual console as well as a vmkernal port for my NFS connectivity. This vswitch is mapped to 1 port on one of the nic’s.

Finally, my last nic port is mapped to a 3rd virtual switch which is for vmotion. This virtual switch contains a service console (on a different subnet than the other service console) and a vmkernel port for vmotion.

With the exclusion of the last nic port which is for vmotion, the other 3 nic ports are connected to my switch as trunk ports where I am tagging about 5-6 different vlans (DMZ, iSCSI, etc…).

Everything seems to work fine, but when I read an in-depth posting like this I wonder I am possibly missing something.

Thanks everyone!!

It’s very common to hear of users having stuff hard-coded in /etc/hosts. You’re not alone in that regard.

DNS will resolve both short and long names. However, you must ensure that your ESX server is properly configured with the right domain name so that short names are placed in the right DNS domain for resolution. This can be done most easily in the VI Client.

I still feel we’re just getting started with ESX. HA and isolation is an area we’ve not really addressed yet.

On a side note I have to admit we were advised to add ESX servers to /etc/hosts although DNS is also working correctly.

However in my hosts file I specify long and short names. Will DNS handle resolving of shortnames? Will the ESX servers apply their DNS suffix when attempting to resolve shortnames?

Good write-up, thanks for the work on this topic. VMware HA is definitely under-documented.

I can see your point about multiple isolation addresses; I guess my point is that I don’t see where multiple isolation addresses REALLY help. Understanding that HA isolation response only kicks in when host-to-host heartbeats are lost AND when the isolation address is unreachable, then providing a second Service Console interface on another subnet makes it VERY unlikely that all host-to-host heartbeats would be lost. Since the host-to-host heartbeats continue, the HA agent never relies upon the presence (or absence) of the isolation address.

Still, it certainly doesn’t hurt to include one…and if it can provide a small improvement in redundancy then I guess it’s worth it, eh?