virtual grind thoughts from the virtual world


Accessing the bash shell in Equallogic

Sometimes I need tools such as traceroute when troubleshooting connectivity between Equallogic arrays. This is especially useful when configuring features like replication.

From the main Equallogic shell, only certain Equallogic specific commands are available. To access the OS level shell, you can simply ssh in to your array and issue the command:

su exec bash

From the bash shell, you can issue OS level commands such as ifconifg and traceroute.


vCloud Director Cell Firewall Settings – Cisco ASA

In a vCloud Director environment, vCD cells are usually placed in a DMZ network. Based on best practices, a load balancer is also used in multi-cell environments, which is placed in front of the vCD cells.

Access to/from the vCD cells should be restricted not only from the public side, but also internally. For instance, vCD cells do need to communicate with a database vlan where a database server lies and a management vlan where services such as vCenter live.

When configuring multiple vlans, certain access lists are placed between the vlans for communication. An example of this would be an access list that allows your vCD cells to communicate with the database vlan. For example, you may have an access list that allows tcp port 1521 (Oracle) from your vCD cells to your database server.

Another issue that may come up are keepalives for tcp streams between your vCD cells on one vlan and your esxi hosts on another vlan. vCloud Director will also email messages such as:

"The Cloud Director Server cannot communicate with the Cloud Director agent on host "hostname". When the agent starts responding to the Cloud Director Server, Cloud Director Server will send an email alert.

If you are using a Cisco ASA environment, this issue can be fixed easily with a feature called Dead Connection Detection.

The following config will allow you to do this:

1. Create an access-list that allows the ip addresses or subnet of your vCD cells:

access-list vcd_dcd extended permit ip host any
access-list vcd_dcd extended permit ip host any


access-list vcd_dcd extended permit ip any

These access lists would allow your vCD cells on and .11 or Note that you can also make this access-list more specific by defining the destination, which would be your esxi hosts or subnet. An example of this would be:

access-list vcd_dcd extended permit ip host host
access-list vcd_dcd extended permit ip host host


access-list vcd_dcd extended permit ip

2. Next, you need to make a class-map:

class-map vcd_keepalive_class
match access-list vcd_dcd

3. Create a policy-map that defines your timeout and dcd settings:

policy-map vcd_keepalive_policy
class vcd_keepalive_class
set connection timeout idle 2:00:00 dcd 0:10:00 3

4. Finally, create a service policy for the interface where your vCD cells reside:

service-policy vcd_keepalive_policy interface INTNAME

* Note that you will change "INTNAME" with the ASA interface (nameif) name.

For reference, this Cisco article covers DCD in detail:

Configuring Connection Limits and Timeouts


Setting Default Path Selection Policy (PSP) – Round Robin

When using a storage technology such as Compellent, the ability to take advantage of multipathing is highly desirable. To utilize multipathing you must select the correct Path Selection Policy (PSP) on each ESX/ESXi host.

By default, the "Fixed (VMware)" path selection policy is selected on a new ESX/ESXi install. As you add volumes across multiple hosts in a cluster, this become a pain to change the path selection to "Round Robin (VMware)" on each volume on each host.

Fortunately, changing the default PSP is very easy with the following esxcli command:

esxcli nmp satp setdefaultpsp --satp="VMW_SATP_DEFAULT_AA" --psp="VMW_PSP_RR"

Please note that you want to first verify your "Storage Array Type" before setting the above policy. For Compellent, as of this post, the storage array type is "VMW_SATP_DEFAULT_AA". Other vendors may require a different type, such as "VMW_SATP_EVA" or "VMW_SATP_EQL".


Quickly Determine An Equallogic Group Lead

When updating firmware (amongst other things) if you quickly need to check which member in a group is the lead, you can do so with the command:

su exec pm member

Simply ssh in to your group IP address or one of the specific member IP addresses and issue the command. Note that this command will also show you some useful statistics as well.

An example of the output from this command is below:

MEMBER-NAME-HERE [1.1447322343] 0-888888-999999-000000 pssId(4) Talisker(10)
total space : 1476818 pages 21633.08GB RAID-5
free space : 39861 pages 583.90GB (3%)
snap space : 0 pages 0.00MB (0%)
repl space : 9490 pages 139.01GB (1%)
status: (Online GL)

GL-group lead, RV-raid verification, BC-battery charging, RR-raid reconstruction

As you can see, some basic stats on the space is presented. In the "status" line, you also see that the member is online and that it contains "GL", which means it is currently the group lead. Via the legend at the bottom, you can also see that there is a possible GL, RV, BC, and RR status on the member as well.