Hello,
I am having problems with network performance between ESX hosts and from Virtual machines to other devices on our network. This is very apparent when copying data between VMs (network speed approx 10MB/sec). I have 4 ESX hosts with approx 7 VMS on each host connected to a Fibre Channel EVA4000 SAN. Copying between drives on different disk groups on the same VM is very quick which suggests the SAN is working fine but everytime the VM has to over the network, speeds are very slow indeed.
Each ESX host has 4 NICS which are teamed but VMotion and Service Console traffic are using the same Virtual Switch as the VMs using VLANS to segregate traffic (Could this be the problem???). All the NICS are set to "autonegogiate" and are using the e1000 network driver.
Copying between VMs on the same host seems to take the longest!!
Any help would be greatly appreciated
Thanks
When using just one vSwitch for VMotion, Service Console and VM traffic you should configure NIC teaming for each portgroup to use specific NIC's.
For example:
Configure the VMotion portgroup te use vmnic3 as active and configure vmnic0, vmnic1 and vmnic2 as standby.
For the Service Console and the VM traffic you do the opposite.
This still doesn't explain the poor network performance.
When you say copying between VM's on the same host takes the longest makes me suspicious about the physical network. Are you copying between VLAN's and is your router the bottleneck or is there somewhere a slow (100Mb/s) link between your physical switches??
- Steven -
I see the exact same problem at a site, except that performance to hosts on the physical network outside the VI3.5u2 cluster is ok.
The setup is 3 ESX hosts connected to FC EVA4100.
Our experience is also that traffic between VMs on the same vSwitch is slowest?
A few tests indicates that changing the virtual nic to vmxnet enhanced solves our problem.
Hi,
Can you select vmxnet with Windows 2003 Standard virtual machines?
Personally I only did the test (on enterprise ed.), but I think that the folks who made the changes in production had to copy the corresponding entries from an ent. configuration file, and paste it into the std. conf. file.
I just checked, and there sure are std. servers running with the vmxnet enh.