OK thanks.
-A single NFS session uses only one uplink, but when there are multiple NFS sessions, wouldn't load based teaming allow the next session to choose the path with the most available bandwidth?
-Thanks for the great tip on pinning vmotion traffic.
-Regarding the place of virtual I/O device , In this case, I'm thinking more specifically around Xsigo than UCS but here is where I'm not clear:
No matter which policy I choose, load based teaming, route based on virtual port id, route based on IP hash, etc, VMware is only using that algorithm to select the virtual nic that will be used to send traffic out. But the decision of which physical Port the traffic goes out on still depends on which physical port that virtual nic is mapped to within the Xsigo director. So all the configuration and tuning I do on VMware doesn't give the hypervisor visibility into how much traffic is going to end up getting crammed on one physical Xsigo port. For example, in a worst case scenario bad design, I could have 10 vnics mapped to one physical Xsigo ethernet port, so that that link gets saturated up to the physical switch, then I could have one virtual nic mapped to only one Xsigo physical NIC port using a10Gb link all to itself which is underuitlized. I wouldn't do that but you see the point, that I can defeat a great virtual networking design in VMware with a bad design on the virtual I/O device. I'm trying to understand more about the interplay between the two configurations and how to make sure the goals I defined before the virtual I/O device was in place by implementing a certain virtual networking configuration in VMware are still being represented once I introduce the virtual I/O device.