ESXi4.1 vMotion using incorrect vmnic

I have a number of esxi 4.1 update 1 hosts configured as follows: –

vSwicth0 – vmnic0, vmnic1, vmnic2, vmnic 6 – all active
VMKernel Port – Management – enabled for Management – Active vmnic0, Standby vmnic2, unused vmnic1 and vmnic6
VMKernel Port – vMotion – enabled for vMotion – Active vmnic2, Standby vmnic0, unused vmnic1 and vmnic6
VMKernel Port – FT Logging – enabled for FT Logging – Active – vmnic1 and vmnic6, standby vmnic0 and vmnic2

Each VMKernel Port only has the function it is intended for enabled and the other two disabled, i.e. the Management VMKernel port is enabled for Management but has vMotion and FT Logging disabled.

When performing a vMotion and monitoring the physical switch I notice traffic coming out of the source host on vmnic0 and going in to the destination host on vmnic2.  This should be coming out of vmnic2 and going in to vmnic2.  It always does this regardless of the source and destination hosts, e.g. if I vMotion a VM from host01 to host02 traffic goes from vmnic0 on host01 to vmnic2 on host02, when vMotioning the VM back from host02 to host01 it goes from vmnic0 on host02 to vmnic2 on host01.

I have also tried separating vMotion and Management onto different vSwitches but still see the traffic coming out of the vmnic configured for management on the source, e.g.

vSwitch0 – vmnic0 acvtive, vnmic1 standby
VMKernel Port – Management – only enabled for Management

vSwitch1 – vmnic2 active,  vmnic6 standby
VMKernel Port – vMotion – only enabled for vMotion

When I perform a vMotion the vmnic0 is used on the source host and vmnic2 on the destination host.

This is all true when vMotion and Management are on the same VLAN/subnet, this should be a valid configuration.

If I change vMotion to use it’s own VLAN/subnet then the correct vmnic is used on the source host but I should not have to do this.

The minor issue I have with using a separate VLAN/subnet for vMotion and Management is that they both use the same VMKernel default gateway so the vMotion interface is now configured for a default gateway which it can never access!  Not a major issue as the vMotion traffic should never need to leave it’s subnet.  Some environments I have the vMotion interface is being monitored by a monitoring utility and this can not access the vMotion interfaces if the default gateway is not accessible.