What exactly does it show when you select a host from the list? It should normally show you the VLAN ID that is not supported. The error usually occurs if you have configured a dvPortgroup with a VLAN ID that does not exist on the physical switch port of an uplink. This usually triggers also the MTU warning for the same VLAN ID.
From the list when you select a host (vDS --> Monitor --> Health --> VLAN Tab), it shows under the "VLAN Trunk" column a value of "0" and under the "VLAN Status" column a value of "Not supported" for 4 of the 6 vmnics listed. The other 2 show "Supported". The vDS port groups are not assigned Vlan IDs/numbers.
For the MTU tab, it shows "Not supported" for the same 4/6 vmnics.
Is this because the vDS is running 5.5, still, in the 6.5.0 environment, and would upgrading first correct this?
Okay. Normally there is a VLAN ID instead of 0, which is missing on the physical switch port. For example: You have created a port group with VLAN ID 10, but VLAN 10 is not configured on the switchports of some uplinks. In this case, the number 10 would be there.
If this is 0, it usually means that you have portgroups where VLAN is set to "none". So the dvSwitch sends the packets from these port groups untagged to the physical switch port. The dvSwitch healthchecks check this, too, but if there is no Native VLAN configured on a trunk port of the physical switch, these frames are dropped and the healthcheck warns about this.
I therefore suspect that the switchport configuration of some uplinks is different. Especially the Native VLAN configuration.
The Native VLAN on the physical switch (HP Flex10) shows as VLAN 1, which I suppose is the default setting. There are 3 Vlans, including VLAN 1 going to this environment. So what is the fix for this if that's the case?
Unfortunately, I'm not familiar with HP switches, especially the Virtual Connect modules. With our Cisco network infrastructure, I simply created a VLAN as a native VLAN on each switchport where an ESXi uplink is connected and the problem was solved. We have no untagged traffic in our infrastructure, so using a "dummy" native vlan was an acceptable workaround.
With Cisco it would be:
switch# conf t
switch(config)# vlan 123
switch(config-vlan)# name VMWARE-NATIVE-DUMMY
switch(config)# int Ethernet1/35
switch(config-if)# switchport trunk allowed vlan add 123
switch(config-if)# switchport trunk native vlan 123
(Interface must be changed)
So, I haven't gotten to the network settings changes or analysis yet since it's a blade server and I'll have to investigate how that was and should be set up vs. how it current is. I also wanted to upgrade the vDS to see if that made any difference...
So I upgraded the vDS from version 5.5.0 to 6.5.0, hoping that might clear something up compatibility-wise. It did not. Now, of the 5-host cluster, 3 of the other hosts now show the same Critical Alerts as the original one I had the issue with, but oddly, one of them does not. That host is running the same OS as the others (minus the one host I had patched) and appears to be configured the same way also. So now 4 of the 5 hosts show the Alert. I'll have to review the network settings on both sides but if you or anyone else has any input or recommendations beyond what's already been recommended here, I'm all ears. Thanks.