Since the switches are bridged, data can flow across the active VM nic path to either IPMP virtual binding. IPMP uses a ping to determine if a path is up. Should a path fail, e.g. a switch failure on either the active or standby path this will result in a transition to the standby side if the active end dies and no change if the standby path fails. IPMP will detect if either side is down and will transfer to the only link which responds. The VM traffic is never active on the standby path when the VM is bound to the team and no failure is present because the standby interface presents no response to the IPMP ping probes.

Regards,

Mike

For eNAS-Interface1 you should define one active and one standby vmnic. This will ensure proper interface fail-over in all failure modes. The VMware NFS kernel instance will only use a single vmnic so your not loosing any bandwidth. The vmnic team only serves as a fault tolerant connection and is not a load balanced configuration.

Since the NAS is configured with IPMP and is connected to two switches, but the VM only has one NIC that is active (the other is standby), then how can does this topology work when traffic flows from the NAS to to switch that the standby cable is connected to?

I have not seen that behavior from VMware however I rarely need to call them, they tend to help first and if they hit a wall they would ask that you rule out the unknown before they proceed.
They also would not go deep into any other vendors system bowels, EMC, NetApp, Various Engineo flavors it’s all the same they will point you to them for a solution. You see the disclaimers on multipathing and round robin in every VMware certified solution doc.

Regards,

Mike

Do you have a sense on what position VMWare takes when dealing with support issues? Does one piece of your environment not being on the supported list cause them to not support the entire setup or make them more likely to blame the piece they don’t “support”?

I find it unlikely that they are going to go deep into the bowels of Solaris 10 to help us with issues regardless of the gear being supported or not.

Thanks again,

Jason

I have not installed ESX4 on the x4500 but I see no reason for it to be an issue. The supported list is only for servers that are certified and with the SUN/Oracle merger it’s going to delay those efforts but will not stop them.
Also I have run the X4500 as an NFS/iSCSI target with ESX4 consumers since it’s release and with the current patch levels. No issues to date.

Regards,
Mike

We’re using a pair of x4500s and the ZFS/NFS combo as part of our ESX 3.5 environment. We are currently planning a migration to vSphere and I notice that the x4500 is only supported on 3.5. Have you heard anything about why this is and more importantly if it will change in the near future?

Thanks in advance,

Jason

Your welcome!

Since your using NFS your best course would be to add a mirrored SLOG to the system. When you do a ZFS snapshot there is a point at which all in flight write requests are committed thus allowing a consistent static state for a snapshot to reference. Without a SLOG this must be committed to the slow physical disk. I highly suspect that is the suspend state your experiencing and moving to OpenSolaris would not resolve that. There are no issues exporting and importing ZFS provided that the source version of ZFS is supported on the target.

Snapshots at the VMware level cause significant increases in VMware disk IO and lock activity and thus it kills your performance.

For your VMware swaps you need to monitor if there is swap activity first. If swapping is occurring I would suggest creating an iSCSI LUN for VMFS and place the swaps on that store at the VMware host level. iSCSI Block storage will not use sync based IO unless the application specifies to do so with a SCSI sync flag and thus you get the benefit of cached IO on that shared swap store.

Using the local disk store is an option as well. I prefer shared stores because it allows fast failure recovery from a hypervisor instance outage.

Regards,

Mike