I have two HP c Class blade chassis, configure in a stacking link via Virtual Connect. I am looking for some input here.
We don't have LACP on the ports where these chassis are connected into, we were going to but never did get a chance to put it in cause when we did it uncovered a bad Flex-10 module so we needed to back it out.
On the ESX side, we had both "Prod" nics set as "active.
On the Virtual Connect side, one uplink is active, the other is standby - this can't be configured, it's how virtual connects picks up the ports from the switch.
I checked the MACS to ensure I was dealing with the same MACs on the Virtual Connect side / ESX side.
I started seeing that VMs were losing their network connectivity, so after many hours w/ Vmware, we determined if we set one NIC on the ESX side to "stand-by" it would resolve the issue...ONLY if that NIC's MAC coincided with what port Virtual Connect set as "Standby".
So in there pictures, vmnic8 communicated to the physical network thru the "Active" port in Virtual Connect.
My "Theory" here is since we do not have LACP enabled on the switch side, I am "guessing" that when we have a VM that this issue comes to life, where it loses it's connectivity, IT (the VM) wanted to used the one NIC where Virtual Connect had it listed as Standby, however on the ESX side both NICs are set as Active, the VM didn't know any better.
We didn't think that LACP would help us at all since the links back to the core are only 1GB unlinks anyway, But now I am beginning to believe that LACP would make both uplinks in Virtual Connect as "Active" so in return it wouldn't matter which NIC (path) a VM can communicate thru.
Feed back is GREATLY appreciated.