Comments on: No Failback Bug in ESX(i)

By: jason

jason — Wed, 28 Apr 2010 15:13:16 +0000

Update 4/27/10: The no failback issue has been root-caused by VMware and a fix has been constructed and is being tested. It will be triaged for a future release.

By: Virtualization Short Take #38 - blog.scottlowe.org - The weblog of an IT pro specializing in virtualization, storage, and servers

Sat, 17 Apr 2010 17:07:11 +0000

[...] Boche describes a bug in the ESX(i) failback behavior (or, more appropriately, the no failback behavior) that could have some pretty serious side effects [...]

By: jason

jason — Wed, 14 Apr 2010 12:52:50 +0000

We definitely examined the terminology. Like I said, I waited several weeks on this before I posted to be sure everyone was on the same page. VMware has confirmed it a bug in that the “no failback” should function whether or not there are standby adapters.

At the very least, if what you are saying is true, then there would be a UI issue because without a standby adapter, the Failback option should be grayed out. I also submitted this piece of information to VMware. They acknowledged it but said that the Failback mechanism is supposed function as selected with or without standby adapters.

By: Packet Racer

Packet Racer — Wed, 14 Apr 2010 09:16:57 +0000

I agree with Duncan. I don’t consider it a bug because in my opinion the “No failback” option only counts when your load balancing is set to “Explicit failover order”. Unless you specify “Explicit failover order” then the vSwitch will do load balancing. The behavior you observed with half of the VMs becoming unpingable is consistent with port ID based load balancing. You should re-try your experiment with load balancing turned off, if you haven’t done so already.

By: jason

jason — Thu, 08 Apr 2010 17:27:45 +0000

This blog post is about the failback: no option not working correctly. Whether set at the vSwitch or Portgroup level, configuring failback to no still allows a recovered VMNIC to take on traffic. The only way to make this work correctly is to configure at least 1 VMNIC as a Standby adapter in conjunction with configuring failback to no.

By: NiTRo

NiTRo — Thu, 08 Apr 2010 17:25:08 +0000

Jason, can you explain “does not work in this case” ? I usualy do this on my enclosures to be sure my vmotion port group will always be on the same nic and so the vmotion trafic won’t go out of the same enclosure switch.

By: jason

jason — Thu, 08 Apr 2010 15:56:23 +0000

Nitro, overriding the vswitch policy at the portgroup level does not work in this case. If you see differently, please let me know.

By: jason

jason — Thu, 08 Apr 2010 15:50:19 +0000

Duncan, I worked quite a bit with VMware support on this to be sure the behavior we were seeing was contra what the documentation described and thus the feature is not working as designed. Having a clear understanding of the feature was the reason I delayed this post for a few weeks. I wanted to be absolutely sure I was not falsely reporting a VMware bug.

By: NiTRo

NiTRo — Thu, 08 Apr 2010 13:31:43 +0000

Jason, indeed it’s a shame but in your case it is possible to set standby adapter and no failback on the vswitch and only override the network policies for the VM port groups. I know it’s not enough and i really can’t understand why VMware isn’t respond to this bug.

By: Duncan

Duncan — Thu, 08 Apr 2010 06:34:07 +0000

I am bit surprised this is labelled as a bug as I always thought it was working as designed because of the following bit in our documentation: “If failback is set to Yes (default), the adapter is returned to active duty immediately upon recovery, displacing the standby adapter that took over its slot, if any.”

The keyword here is the word “standby”. I assumed it only applied in an active/standby scenario.

Keep us up to date,