Besides the issues of not having enough IP space, I think the biggest issue with this change is that VMWare has taken something that worked in VC2.5u1 and previous, changed the requirements, made no notification of said change, and made no way to work around it. If I was with my previous employer I know they would have their legal people looking into this since that was the way they operated. On top of all that there is no way to test out the upgrades to the rest of the products without upgrading to VC2.5u2 first (at least to be able to test out through VC), and the roll back works for crap...I had to roll back to u1 becasue of a failure during the upgrade..and that hosed the DB even more...the roll back means you restore from backup tape. All that being said, I would have been at least a little more tolerant of the change if I had been made aware of it PRIOR to performing the upgrade...in the release notes...but I am guessing that would have been too much to ask for....

I appreciate your frustration. You are right, this change was not properly communicated in the release notes.

One correction, though....

There never used to be a cluster configuration validity check, so improper configurations were unrecognized. While things may have appeard to be working properly, the cluster was vulnerable when there wasn't complete network compatibilty. This is due to the way the cluster communication multi-paths its cluster communication over the available networks. Certain host restart scenarios could lead to split-brain conditions (where the cluster divides into two separate clusters). Also, the heartbeats would never be recieved over non-routable networks, leading to degraded host failure detection.

And I agree, the upgrade process is painful for large installations. That is something we are committed to improving.

How do you configure for 2 consoles on separate subnets? It only gives me the option to set the default console gateway but I would like to put a console on another subnet.

Ok, so how does one use this das.allowNetwork feature?
I keep getting "Object reference not set to an instance of an object." errors.

I have two vlans I'm trying to work with. 3 of my hosts are on 1 vlan, and the rest are on another..

So what is the correct way to express them?

das.allowNetwork195 Service Console
das.allowNetwork228 Service Console

Tried the above and it didn't fix it. Also, if I just create a das.allowNetwork1, and 2 it seems to pre-populate the vlans after I've reconfigured the cluster.
I just need an example to go off of because I'm not getting this to work.

To be clearer, if you have a single Service Console on each ESX host, then they all need to be on the same IP subnet (even if you know better and are using routable VLANs).

VMware will have to create a patch to "ignore the network compatibility check", which isn't currently in the U2, otherwise, for those who don't have the flexibility to modify their Service Console IP networks, there is no workaround.

Hello, I have the same problem, my cluster has 2 ESX and the service console (one NIC/ESX) is in different VLANs. Today I have called the vmware support to open a ticket and now I wait for a answer. In my environment it is not fatal HA does not work but in few weaks, it must be work The vmware solution in KB 1006541 does not work for me My other cluster with no installed Update 02 works fine.

Thanks for all postings

so once you add the das.allowNetwork into the HA advanced settings, and it doesn't work, how do you remove the entry?
deleting and ok'ing looks ok, but go back in and it's back!

we have 4 NICs
1 for vmotion (same subnet)
1 for vmkernel (different subnet)
2 for trunked VLANs

so do we run HA on the vmkernel network? or the VLAN'ed networks (3x same subnets). No this fails.

do we use the vmotion network then? sounds all wrong to me.

If you want to remove that setting http://das.allowNetwork you cannot. When I called into VMWare support on this issue initally the tech took it as a bug report. The only way to remove that setting would be to create a new cluster and move all of your ESX hosts to that new cluster which does not have that setting specified.

Just one more bug from VMWare as of late.

The can sit there all day and say that this HA issue wasn't a bug, but in not telling people that they were making a change to the requirements it is in fact a bug..or, having worked for many software companies a "new feature." It just shows that their quality control and documentation as of late has been horrible I keep bringing up to my VMWare SE that they are following in the steps of Microsoft with code releases and lack of testing...and that is not an enviably quality of Microsoft's to emulate!