Installing Dell Equallogic Multipathing Extension Module (MEM) in vSphere 5.1

Dell offers a Multipathing Extension Module (MEM) for vSphere, and in this post I´ll highlight how to “manually” install it on a ESXi 5.1 host. I will not cover the network setup part of the equation, but rather go through the simple steps required to get the MEM installed on the hosts in question.

First of all, you need to download the MEM installation package. At the time of writing, the latest version is v1.1.2.292203, available from One the archive file is aquired, unzip it and upload the file to a shared location available in your environment. For the example below, I have used a VMFS datastore that is available to all the hosts in this particular cluster.

Note: The host in question has already been put in maintenance mode, to make sure no VMs are actively using the storage paths while installing the module.

The VIB file, which resides inside the, file can be installed using several techniques; By using the vMA, vSphere Command-Line Interface (vSphere CLI), vSphere Update Manager or even by logging in to the hosts via a SSH connection, and in this case I opted for doing it through SSH.

The command required to install the MEM is as follows:

[cc lang=”bash” width=”100%” theme=”blackboard” nowrap=”0″]
esxcli software vib install –depot /vmfs/volumes/vmfsvol/dell/[/cc]

A completed installation looks like this:

[cc lang=”bash” width=”100%” theme=”blackboard” nowrap=”0″]

login as: root
Using keyboard-interactive authentication.
The time and date of this login have been sent to the system logs.

VMware offers supported, powerful system administration tools. Please
see for details.

The ESXi Shell can be disabled by an administrative user. See the
vSphere Security documentation for more information.
~ # esxcli software vib install –depot /vmfs/volumes/vmfsvol/dell/
Installation Result
Message: Operation finished successfully.
Reboot Required: false
VIBs Installed: Dell_bootbank_dell-eql-host-connection-mgr_1.1.1-268843, Dell_bootbank_dell-eql-hostprofile_1.1.0-212190, Dell_bootbank_dell-eql-routed-psp_1.1.1-262227
VIBs Removed:
VIBs Skipped:
~ #[/cc]

I then restart the hosts process, to make sure that the multipath module is activated.

[cc lang=”bash” width=”100%” theme=”blackboard” nowrap=”0″]
~ # /etc/init.d/hostd restart
watchdog-hostd: Terminating watchdog process with PID 9592
hostd stopped.
hostd started.
~ #[/cc]

Finally, a quick check to see if the new Equallogic namespace is available, and that it is gathering statistics, i.e. being used:

[cc lang=”bash” width=”100%” theme=”blackboard” nowrap=”0″]
~ # esxcli equallogic stat summary
DeviceId VolumeName PathCount Reads Writes KBRead KBWritten
——————————– ———- ——— —– —— —— ———
6090A098E0DC5D9F71E6940292F8569C vmvolume 2 2573 30 20429 14
6090A098D06C5A31CEDE44CC17CBF14B test2t 2 651 30 13028 14
6090A098D06C4AF067EDD4C904C6A453 vmvolume3 2 642 30 10592 14
6090A098C08D5E928EE634938F42605B vmvolume1 2 1834 30 20023 14
~ #[/cc]




Screenshots displaying the ESXi host path policy before:







and after installing the Dell Equallogic MEM:



Installing and Configuring WANem Virtual Appliance



In a previous post, Using the WANem WAN Emulator Virtual Appliance, I’ve talked about how I’ve successfully used WANem to emulate different WAN scenarios.

Since I work for a shipping company, the ability to emulate VSAT conditions are especially useful for testing and proof-of-concept scenarios.

You can use WANem a couple of different ways but my setup is pretty simple but does the job perfectly.

Downloading WANem

I have chose to use the WANem Virtual Appliance running in a virtual machine hosted by VMware Workstation. If you don’t have Workstation handy, VMware Player will also do the job. You don’t need to use the virtual appliance, as WANem also offers a bootable ISO download that you could boot your VM from

Starting and configuring WANem

First off, extract the file, and place the virtual machine files in a know location. My choice is c:\virtual machines\ but you will have to adjust that for your specific environment.

Secondly, fire up VMware Workstation and chose the “Open existing VM or Team” option

In the file dialog box browse to where you extracted the virtual machine files and select “Open”

I like to run the WANem VM in bridge mode, since this gives the VM it’s own IP address from my DHCP server. This comes in handy later when we setup what traffic we want to route through WANem.
By default the VM is configured in “Bridge Mode” which is the network mode we want, so go ahead and start the VM by pressing the “Power on this virtual machine” option.

The WANem VM starts to boot up, but it stops asking if you want to configure all network interfaces via DHCP.

As I use DHCP in my network, I don’t have to specify any network information so I hit ‘y’ to let it continue booting.
Once again the boot process stops, this time asking you to specify a root password for the VM. Provide your own password twice, and the boot process is finished. Don’t worry about the password strength, or even if you remember it later. The VM boots on a pre-configured Knoppix LiveCD, and the next time you start it it will ask for a new password.

If you don’t see the IP address that WANem has received from your DHCP server, type status and hit enter, and it will show you the IP it has been assigned.

Open your favorite browser, and point it to http://WANemIP/WANem (in my case this was

And there it is, WANem is up and running. We’ll leave it as is for the time being, and start routing traffic through it as is.

Running IP traffic trough WANem

You have a couple of choices when it comes to routing your traffic through WANem. The easiest setup si where you set WANem as your default gateway and route all traffic through it. Remember though that this only comes into play if your destination is on another subnet than the one you are currently connected to. In many scenarios this isn’t desirable, and I prefer to route specific traffic through WANem and not have to play around with my DHCP assigned settings.

What I usually do, is to drop into cmd in administrator mode, and issue the following command:

route add {destination IP} mask {WANem IP}

This routes all traffic from the computer I run the command on, through the WANem IP address, and from there on it goes to it’s original destination. This allows it to work on local subnet traffic, as well as remote traffic, and it will not affect any other IP traffic from that computer to the rest of the network.

Obviously, we need a destination as well. For this lab setup I decided to route the traffic to my local printer through WANem. It’s ip is, so the command to run inside cmd as administrator is:

route add mask

Now, all traffic from my local computer to my printer is routed through WANem. For now, nothing much happens. WANem receives the data on it’s network card, and promptly sends it on it’s merry way to the final destination; my printer. No innocent packets have been mauled or otherwise hurt in the process, at least not so far.


If you want to route everything even local subnet traffic through WANem, enter the following command:

route add mask {WANem IP}
See this comment for context.

Tweaking WANem settings

Finally, the fun part! Now we can start playing around with those innocent little network packets that flow through the network. Ever wanted to know what happens if you try to print to a printer over a 128kb WAN link? Well, now you can! I would strongly advise against trying to print your über 120 slide PowerPoint presentation at this point, but you can if you want to. Possibly.

I’m not going to try to print over the link as it is now, we’ll have to settle for a little demonstration using much simpler means.

Tool of choice the ever faithfull ping. Basically I’ll demonstrate how WANem fiddles with your network traffic. First off, a just a normal ping of my printer with no edits done by WANem what so ever:

As you can see, as this is on my local network, the response time is great at 1ms and no dropped packets.

Now we can open the WANem web interface, and start messing about. Click on “Advanced Mode” and then on the “Start” button to bring up the web interface.

The next screen brings up a lot of options, and we’re going to tweak a couple of them.

I set the “Delay Time (ms)” to 200ms and the “Loss %” to 25%, and hit “Apply Settings”. When we turn back to our cmd window, we should see instant results in our ping monitor.

As you can see, the response time is now approximately 200ms and the packet loss is about 25%, in accordance with the settings I’ve applied. Of course, as you can see, there are lots of other settings to play around with as well.

WANem also allows you to save your settings, so if you find your own perfect little real world emulation scenario you can export the settings and re-apply them later if you wish.

Cleaning house

When testing is over, be sure to remove your static route(s) again. If you don’t, and you power down your WANem appliance you simply will not be able to reach your destination(s) until it’s powered on again. Thankfully, removing the static routes are as easy as adding them in the first place. The command to run, in an administrative mode cmd is:

route delete {destination IP}


WANem is a very nice, and simple to set up, little appliance that could make it much easier planning deployments and emulating real world scenarios. After all, do you know how your applications behave if they get high latency connections? Or if you get jitter problems or even dropped packets?

Give it a test, you might just get a bit surprised at the results you get.