Archives For December 2010

Merry Christmas!

December 22, 2010 — Leave a comment

With this picture of our son Jaime and our lady Buffy, my wife and me wish to you and your families all the best for this Christmas and the New Year ahead.

And I hope that Santa and the Three Wise Men bring everything you asked for your homelabs ;-)


In the first post of the series I introduced to you HP Virtual Connect and showed how to use the Domain Wizard Setup to initially configure a VC domain. In the following article I will outline the use of the Network Setup Wizard and explain Virtual Connect networking concepts.

Before we begin to setup the network it would be very useful to clarify the Virtual Connect port terminology.

  • External port – The Ethernet connectors SFP+ modules (either 1GB or 10GB), 10GBASE-CX4 and RJ-45 on the faceplate of the Ethernet module.
  • Stacking port – These are Ethernet external ports used to connect within a Virtual Connect Domain the VC Ethernet modules. The Ethernet modules automatically identify the stacking modules.
  • Uplink port – An external port configured within a Domain for use as a connection to the external networking equipment. These ports are defined within Virtual Connect by the enclosure name, interconnect bay that contains the module and the port number.
  • Uplink port set – A set of uplinks ports trunked together in order to provide improved throughput and availability.
  • Shared uplink port – This is an Ethernet uplink port that carries the traffic for multiple networks. The associated networks are mapped to a specific VLAN on the external connection, the appropiate VLAN tags are removed or added as Ethernet packets enter or leave the VC Domain.
  • Shared uplink port set – This is a group of Ethernet uplinks trunked to provide improved throughput and availability to VC Shared Uplink Set.

The Virtual Connect Network Setup Wizard will help to establish external Ethernet connectivity for the enclosure. With this wizard you will be able to:

  • Identify the MAC addresses to be used by the servers within the VC Domain.
  • Configure Server VLAN tagging.
  • Set up connections from the c-Class enclosure to the external networks.

The network connections can be:

  • Dedicated uplink to a specific Ethernet network.
  • Shared uplink sets.

The first screen of the wizard is the MAC Address Settings. As every server in the market the HP Blades come with factory-default MAC addresses already assigned to their network cards. However Virtual Connect can override these values while the server remains in the enclosure.

Virtual Connect access the NICs through the Onboard Administrator and the server iLO to manage the MAC addresses. It provides 64 predefined and reserved MAC address ranges. The wizard will give you the option to use either an HP predefined range or an user defined one. HP recommends to use the predefined ranges.

Once you have chosen the address range and click next the wizard will ask for confirmation before continue.

The next screen is Server VLAN Tagging Support. Here the wizard gives you two possible options:

  • Tunnel VLAN Tags
  • Map VLAN Tags

The first one, Tunnel VLAN Tags, supports only VLAN tagging on networks with dedicated uplinks where all VLAN tags passed through the VC Domain without modification and ports connected to networks using shared uplinks can only send and receive untagged frames.

On the other hand Map VLAN Tags allow you to add more than one network to an Ethernet server port and specify the VLAN mapping between server tags and VC-Enet networks. Also, the VLAN tunneling will be disabled for VC Ethernet networks with dedicated uplinks.

There is also a checkbox in the page to , if this option is enabled the server ports connected to multiple VC Ethernet networks are forced to use the same VLAN mappings as those used for the corresponding Shared Uplink Set and the network connections can only be selected from a single Shared Uplink Set. When this option is not checked server network connections can be selected from any VC network and the external VLAN ID mappings can be manually edited. In the example of the screenshots I decided to check it.

Below are another two optional settings for link speed control when using mapped VLAN tags. These settings are:

  • Set a Custom value for Preferred Link Connection Speed. This value applies to server profiles with a Multiple Networks connection defined and the Port Speed Setting set to Preferred.
  • Set a Custom value for Maximum Link Connection Speed. This value limits the maximum port speed for multi-network connections when a Custom port speed is specified.

In our example we’re not going to check neither of them . Click next to move into the Define Network Connection screen.

Choose the network type you want to define and click next. I choose .

The Define Single Network shows up. First define the network name (prod_net_01 in my example). There are three configurable values.

  • Smart Link – With this option enabled Virtual Connect will drop the Ethernet link on every server connected to that network if the link to the external switches is lost.
  • Private Network – This option is intended to provide extra network security by isolating all server ports from each other within the VC Domain. All packets will be sent through the VC Domain and out the uplinks ports so the communication between the severs will go through an external L3 router that will redirect the traffic back to the Domain.
  • Enable VLAN Tunneling.

Click in the Advanced button to configure Advanced Network Settings. Set the network link speeds that best suites your configuration.

Again from the Define Single Network page we are going to assign a port to our network. Click on Add Port and select an uplink port.

Set the Connection Mode to Auto if the ports are trunked and to Failver if not.

Click Apply and move onto the next screen. From this screen you can create as many additional networks as you need.

Now we are going to create a network using VLAN tagging. Click Next an move again into the Define Network Connection page, select Connection with uplink(s) carrying multiple networks (using VLAN tagging) and click Next. The Define Shared Uplink Port Set page will be displayed.

A shared uplink is the way Virtual Connect has to identify which uplinks carry multiple networks over the same cable. On shared uplinks the VLAN tags are added when packets leave the enclosure and added when leave. The external switch and the Virtual Connect Manager must be configured with the same VLAN tag ID for each network  on the shared uplinks. The uplinks enables multiple ports to be added in order to support port aggregation and link failover, with a consistent set of VLAN tags. Virtual Connect has no restriction on which VLAN IDs can be used so the VLANs already used in the external infrastructure can be used here.

Since the VLAN tags are removed or added as soon as the packect enter or leave VC Ethernet Module shared uplink they have no relevance after the packet enter the enclosure. By identifying an associated network as the native VLAN will cause all untagged incoming packets to be placed onto this network, just one network can be designated as the native VLAN.

To finish the network creation assign a name (up to 64 characters with no spaces), add a port using the drop-down menu like in the single network process described above and add the networks you want to associate to the uplink. Finally click Apply.

In the final screen you will see now the three networks associated to a Shared Uplink Set. You can check this also from the Virtual Connect Manager page in the Ethernet Networks area.

And we are done with the Network Setup, in the next post I will show the storage part. As always any feedback would be welcome :-)


A friend asked me last week if I could produce a document for him explaining the initial basic setup of Virtual Connect, I decided that instead of  that it would be better and more helpful to write in a series of blog posts, here it is the first of them for you to enjoy.

Virtual Connect is a technology developed by Hewlett-Packard for the HP BladeSystem c-Class enclosures. Provides server-edge and I/O virtualization in order to simplify the setup, maintenance and administration of server connections. It comprises a set of interconnect modules, both Ethernet and Fibre Channel, and a software known as Virtual Connect Manager.

Virtual Connect Manager, or VCM, is the single point administration interface for Virtual Connect. Under the hoods VCM is a software embedded into the VC Ethernet module, it can be accessed through a web-based interface or command line either with a serial connection to the Ethernet module or through a SSH connection to the module.

From the VCM only a single domain, with up to four enclosures, can be managed.

For large-scale infrastructures there is a more scalable version of VCM known as Virtual Connect Enterprise Manager, or VCEM. Unlike VCM, Virtual Connect Enterprise Manager is not embedded into the VC-Enet module, is a separate software that must be installed in another server. VCEM extends the VC management capabilities up to 250 domains and hundreds of blade servers.

Current series of articles will focus only on the Virtual Connect Manager GUI. Please take into account that I’m using Virtual Connect 3.10 version in the whole series and there some differences with the VC 2.x revisions.

When you login into the VCM for the first time a series of wizards will show up to help you with the initial setup of the domain. This article will cover the first of those wizards, the Domain Setup Wizard.

This wizard will allow you to:

  • Import enclosure configuration and communication settings
  • Name the domain
  • Set the IP address of the Virtual Connect Manager
  • Set up the local user accounts and its permissions and privileges
  • Confirm that the stacking links provide connectivity and redundancy

After the informative screen the first step will display. Here you have to provide the enclosure Onboard Administrator IP address and credentials, these credentials must have administrative level. Click next when finish.

Now VC Domain Wizard will import all the servers and VC interconnect modules within the enclosure.

In the next screen select the enclosure to import and click next.

A pop-up will show up to inform that the networking of all the blades within the enclosure will be disabled until VC Networking is properly configured. of course it will ask for confirmation.

After finishing the import the wizard will go the General Settings part. The Domain Setup Wizard automatically assigns a domain name based on the enclosure name, you can change the name when running the setup wizard or at any time later from the Domain Settings screen. The Virtual Connect domain name should be unique and can be up to 31 characters without spaces or special characters.

Next step is to configure the local user accounts.

By default the only local account is Administrator, this account cannot be deleted nor have domain privileges removed. You can also add up to 32 accounts with a combination of up to four levels of access. The available levels are:

  • Virtual Connect Domain
  • Server
  • Networking
  • Storage

There is also an Advanced area for each account where you can set Strong Passwords requirement and the minimum password length.

With this the Domain Setup Wizard is done. In the next article I will write about the network setup of the enclosure using the Network Setup Wizard.


In yesterday’s post I showed how to get the iSCSI iqn from an ESX(i) server using the vSphere CLI from the vMA and from the root shell of ESX itself. Today it’s turn to use PowerCLI to perform the same task.

The approach to be taken is very similar to the one we used to manage the multipathing configuration.

[vSphere PowerCLI] C:\> $h = Get-VMhost esx02.mlab.local
[vSphere PowerCLI] C:\> $hostview = Get-View $
[vSphere PowerCLI] C:\> $storage = Get-View $hostview.ConfigManager.StorageSystem
[vSphere PowerCLI] C:\>
[vSphere PowerCLI] C:\> $storage.StorageDeviceInfo

HostBusAdapter              : {,,,}
ScsiLun                     : {,}
ScsiTopology                : VMware.Vim.HostScsiTopology
MultipathInfo               : VMware.Vim.HostMultipathInfo
PlugStoreTopology           : VMware.Vim.HostPlugStoreTopology
SoftwareInternetScsiEnabled : True
DynamicType                 :
DynamicProperty             : 

[vSphere PowerCLI] C:\>
[vSphere PowerCLI] C:\> $storage.StorageDeviceInfo.HostBusAdapter | select IScsiName


[vSphere PowerCLI] C:\>


When you are trying to configure iSCSI of and ESX(i) server from the command line is clear that at some point you are going to need the iqn. Of course you can  use the vSphere Client to get the iqn but the Unix Geek inside me really wants to do it from the shell.

After a small research through the vSphere CLI documentation and several blogs I found this post by Jon Owings (@2vcps).

First list the SCSI devices available in the system to get the iSCSI hba.

[root@esx02 ~]# esxcfg-scsidevs -a
vmhba0  mptspi            link-n/a  pscsi.vmhba0                            (0:0:16.0) LSI Logic / Symbios Logic LSI Logic Parallel SCSI Controller
vmhba1  ata_piix          link-n/a  ide.vmhba1                              (0:0:7.1) Intel Corporation Virtual Machine Chipset
vmhba32 ata_piix          link-n/a  ide.vmhba32                             (0:0:7.1) Intel Corporation Virtual Machine Chipset
vmhba33 iscsi_vmk         online    iscsi.vmhba33                           iSCSI Software Adapter         
[root@esx02 ~]#

After that Jon uses the command vmkiscsi-tool to get the iqn.

[root@esx02 ~]# vmkiscsi-tool -I -l vmhba33
iSCSI Node Name:
[root@esx02 ~]#

Beauty, isn’t it? But I found one glitch. This method is done from the ESX root shell but how do I get the iqn from the vMA? Some of my hosts are ESXi and even for the ESX I use the vMA to perform my everyday administration tasks.

There is no vmkiscsi-tool command in the vMA, instead we are going to use the vicfg-iscsi or the vicfg-scsidevs command.

With vicfg-scsidevs we can obtain the iqn listed in the UID colum.

[vi-admin@vma ~][esx02.mlab.local]$ vicfg-scsidevs -a             
Adapter_ID  Driver      UID                                     PCI      Vendor & Model
vmhba0      mptspi      pscsi.vmhba0                            (0:16.0) LSI Logic Parallel SCSI Controller
vmhba1      ata_piix    unknown.vmhba1                          (0:7.1)  Virtual Machine Chipset
vmhba32     ata_piix    ide.vmhba32                             (0:7.1)  Virtual Machine Chipset
vmhba33     iscsi_vmk   ()       iSCSI Software Adapter
[vi-admin@vma ~][esx02.mlab.local]$

And with vicfg-iscsi we can get the iqn providing the vmhba device.

[vi-admin@vma ~][esx02.mlab.local]$ vicfg-iscsi --iscsiname --list vmhba33
iSCSI Node Name   :
iSCSI Node Alias  :
[vi-admin@vma ~][esx02.mlab.local]$

The next logical step is to use PowerCLI to retrive the iqn, but I’ll leave that for a future post.


During a previous project I had the opportunity to work very closely with the EMC people and Symmetrix arrays, in fact I got a couple of very good friends from that project. At the time I created a bunch of text files for my self  reference about EMC SRDF and Timefinder technologies.

Today I decided to review that files, give them some order, well sort of, and put them here as a survival guide/quick reference in the hope that will be of help to any of you. The first of this guides will be about EMC Symmetrix Timefinder.

I don’t have sample output for every command, been more than a year since the last time I work with Timefinder, to complement my own samples I got several outputs from the Timefinder manuals.

This is not a complete Timefinder usage guide, just my personal notes taken from my direct experience with product. 

Timefinder Basics

EMC Timefinder is a replication solution that creates full volume copies. For the full-HP guys out there this is very similar to the XP or EVA Business Copy product.

There are two basic types of replication:

  • TimefinderClone – Creates point-in-time copies.
  • Timefinder/Snap – Creates pointer-based replicas, snapshots, only the changed data is written.

There are several optional components.

  • Timefinder/Mirror.
  • Timefinder/CG (Consistency Groups)
  • Timefinder/EIM (Exchange Integration Modules)
  • Timefinder/SIM (SQL Integration Modules)

Timefinder allows to retain multiple copies at different checkpoints for lowered RPO and RTO.

Symcli basics

Following is a list of the most basic symcli commands necessary to get your way around when you perform any Symmetrix task, including Timefinder.

– Get the list of the Symmetrix devices

root:/# symdev list
Symmetrix ID: 00029xxxxxxx
        Device Name           Directors                  Device
--------------------------- ------------- -------------------------------------
Sym  Physical               SA :P DA :IT  Config        Attribute Sts      (MB)
--------------------------- ------------- -------------------------------------
0000 Not Visible            ???:? 01A:C0  BCV           Asst'd    RW       8632
0001 Not Visible            ???:? 16C:D0  BCV           Asst'd    RW       8632
0002 Not Visible            ???:? 01B:D0  BCV           Asst'd    RW       8632
0003 Not Visible            ???:? 16D:C0  BCV           Asst'd    RW       8632
0048 Not Visible            ???:? ???:??  VDEV          N/Grp'd   RW       8632
0049 Not Visible            ???:? ???:??  VDEV          N/Grp'd   RW       8632
004A Not Visible            ???:? ???:??  VDEV          N/Grp'd   RW       8632
004B Not Visible            ???:? ???:??  VDEV          N/Grp'd   NR       8632
004C Not Visible            ???:? ???:??  VDEV          N/Grp'd   NR       8632
004D Not Visible            ???:? ???:??  VDEV          N/Grp'd   NR       8632
004E Not Visible            ???:? ???:??  VDEV          N/Grp'd   NR       8632
004F Not Visible            ???:? ???:??  VDEV          N/Grp'd   NR       8632
0050 Not Visible            ???:? ???:??  VDEV          N/Grp'd   NR       8632
0051 Not Visible            ???:? ???:??  VDEV          N/Grp'd   NR       8632
0052 Not Visible            ???:? 16B:D1  2-Way Mir     N/A (SV)  RW       8632
0053 Not Visible            ???:? 01C:C0  2-Way Mir     N/A (SV)  RW       8632
0054 Not Visible            ???:? 16B:C0  2-Way Mir     N/A (SV)  RW       8632

– List all available devices from a device group

root:/# symld -g dg_oradev_01 list

– List host physical devices

root:/# sympd list

– List the disk groups:

root:/# /usr/symcli/bin/symdg list

                       D E V I C E      G R O U P S

                                                          Number of
 Name               Type     Valid  Symmetrix ID  Devs   GKs  BCVs  VDEVs

 dg_oracle_prod1    REGULAR  Yes    00029xxxxxxx    26     0    26      0
 dg_oracle_prod2    REGULAR  Yes    00029xxxxxxx    21     0    21      0
 dg_rac_01          RDF1     Yes    00029xxxxxxx    23     0    23      0
 dg_clvx_01         RDF1     Yes    00029xxxxxxx     5     0     5      0
 dg_oradev_01       REGULAR  Yes    00029xxxxxxx     3     0     0      0
 dg_timetest_02     RDF1     Yes    00029xxxxxxx    16     0    16      0
 grupo1             RDF1     Yes    00029xxxxxxx    22     0     0      0


– Add devices to a disk group

  • Add physical devices
root:/# symld -g dg_oradev_01 add pd /dev/dsk/c2t4d12
  • Add Symmetrix devices
root:/# symld -g dg_oradev_01 add 006E

– Get diskgroup detailed info.

root:/# /usr/symcli/bin/symdg show dg_prod_01

Group Name:  dg_prod_01

    Group Type                                   : RDF1     (RDFA)
    Device Group in GNS                          : No
    Valid                                        : Yes
    Symmetrix ID                                 : 00029xxxxxxx
    Group Creation Time                          : Mon Nov 29 18:49:29 2007
    Vendor ID                                    : EMC Corp
    Application ID                               : ECC

    Number of STD Devices in Group               :    2
    Number of Associated GK's                    :    0
    Number of Locally-associated BCV's           :    2
    Number of Locally-associated VDEV's          :    0
    Number of Remotely-associated VDEV's(STD RDF):    0
    Number of Remotely-associated BCV's (STD RDF):    0
    Number of Remotely-associated BCV's (BCV RDF):    0
    Number of Remotely-assoc'd RBCV's (RBCV RDF) :    0

    Standard (STD) Devices (2):
        Sym               Cap
        LdevName              PdevName                Dev  Att. Sts     (MB)
        DEV001                N/A                     01C8      RW      8714
        DEV002                N/A                     01C9      RW      8714

    BCV Devices Locally-associated (2):
        Sym               Cap
        LdevName              PdevName                Dev  Att. Sts     (MB)
        BCV001                N/A                     08A8      RW      8714
        BCV002                N/A                     08A9      RW      8714

    Device Group RDF Information
        RDF Type                               : R1
        RDF (RA) Group Number                  : 2               (01)

        Remote Symmetrix ID                    : 000287xxxxxx

        R2 Device Is Larger Than The R1 Device : False

        RDF Pair Configuration                 : Normal
        RDF STAR Mode                          : False

        RDF Mode                               : Synchronous
        RDF Adaptive Copy                      : Disabled
        RDF Adaptive Copy Write Pending State  : N/A
        RDF Adaptive Copy Skew (Tracks)        : 32767

        RDF Device Domino                      : Disabled

        RDF Link Configuration                 : Fibre
        RDF Link Domino                        : Disabled
        Prevent Automatic RDF Link Recovery    : Disabled
        Prevent RAs Online Upon Power ON       : Enabled

        Device RDF Status                      : Ready           (RW)

        Device RA Status                       : Ready           (RW)
        Device Link Status                     : Ready           (RW)

        Device Suspend State                   : N/A
        Device Consistency State               : Disabled
        RDF R2 Not Ready If Invalid            : Disabled

        Device RDF State                       : Ready           (RW)
        Remote Device RDF State                : Write Disabled  (WD)

        RDF Pair State (  R1 <===> R2 )        : Synchronized

        Number of R1 Invalid Tracks            : 0
        Number of R2 Invalid Tracks            : 0

        RDFA Information:
            Session Number                     : 1
            Cycle Number                       : 0
            Number of Devices in the Session   : 491
            Session Status                     : Inactive

            Session Consistency State          : N/A
            Minimum Cycle Time                 : 00:00:30
            Average Cycle Time                 : 00:00:00
            Duration of Last cycle             : 00:00:00
            Session Priority                   : 33

            Tracks not Committed to the R2 Side: 0
            Time that R2 is behind R1          : 00:00:00
            R1 Side Percent Cache In Use       :  0
            R2 Side Percent Cache In Use       :  0



Timfinder commands

– Associate BCVs to a device group. There are two ways:

root:/# symbcv -sid xxxx -g dg_oradev_01 associate dev 0001

– Establish the mirrors

root:/# symmir -g dg_oradev_01 -full establish DEV001 BCV001

– Split operations.

root:/# symmir -g dg_oradev_01 split

There are several additional split modes and/or modifiers.

  • Instant
root:/# symmir -g dg_oradev_01 split -instant
  • Force
root:/# symmir -g dg_oradev_01 split -force
  • Differential
root:/# symmir -g dg_oradev_01 split -differential
  • Reverse
root/# symmir -g dg_oradev_01 reverse split
  • Reverse differential
root:/# symmir -g dg_oradev_01 reverse split -differential

– Restore the BCV mirrors. The restore operation will copy the data from the BCV to the Standard device.

  • Differential restore
root:/# symmir -g dg_oradev_01 restore
  • Full restore
root:/# symmir -g dg_oradev_01 -full restore

– Reestablish operations. It is very important to tell the difference between Restore and Reestablish. Reestablish will do a differential update from the Standard device to the BCV device.

root:/# symmir -g dg_oradev_01 establish

– Get the list of BCV devices

root:/# symbcv list

Symmetrix ID: 00029xxxxxxx
              BCV Device                   Standard Device          Status
------------------------------------ --------------------------- ------------
                              Inv.                        Inv.
Physical         Sym RDF Att. Tracks Physical        Sym  Tracks BCV <=> STD
------------------------------------ --------------------------- ------------
Not Visible      0030    (M)       0 N/A             N/A       0 NeverEstab
Not Visible      0031    (m)       - N/A             N/A       - NeverEstab
c4t1d0s2         0088              0 c4t0d0s2        0084      0 Split
c4t1d1s2         0089              0 c4t0d1s2        0085      0 Split
c4t1d2s2         008A              0 c4t0d2s2        0086      0 Split
c4t1d3s2         008B              0 c4t0d3s2        0087      0 Split

– Get the state of mirroring of the device pairs within a device group

root:/# /usr/symcli/bin/symmir -g dg_oracle_prod_01 query

Device Group (DG) Name: dg_oracle_prod_01
DG's Type             : RDF1
DG's Symmetrix ID     : 00029xxxxxxx

     Standard Device                    BCV Device                  State
-------------------------- ------------------------------------- ------------
                    Inv.                                  Inv.
Logical        Sym  Tracks Logical              Sym       Tracks STD <=> BCV
-------------------------- ------------------------------------- ------------

DEV001         0184      0 BCV001               039C *         0 Split
DEV002         0186      0 BCV002               039E *         0 Split
DEV003         0187      0 BCV003               039F *         0 Split
DEV004         0188      0 BCV004               03A0 *         0 Split
DEV005         0189      0 BCV005               03A1 *         0 Split
DEV006         018E      0 BCV006               03A6 *         0 Split
DEV007         018F      0 BCV007               03A7 *         0 Split
DEV008         0190      0 BCV008               03A8 *         0 Split
DEV009         0191      0 BCV009               03A9 *         0 Split
DEV010         01C7      0 BCV010               08A7 *         0 Split
DEV011         01CD      0 BCV011               08AA *         0 Split

Total              -------                               -------
  Track(s)               0                                     0
  MB(s)                0.0                                   0.0


(*): The paired BCV device is associated with this group.


– List all BCV sessions in a Symmetrix array

root:/# symmir list -sid xxxx

Symmetrix ID: 00000000xxxx

  Standard Device       BCV Device              State
-------------------- ----------------------- --------------
           Invalid             Invalid   GBE
Sym        Tracks     Sym      Tracks         STD <=> BCV
-------------------- ----------------------- --------------
002B               0 0E0B            0   ... Synchronized
002E               0 0E00            0   ..X Synchronized
002E               0 0E0A            0   ... Synchronized
0032               0 0E0F            0   ... Split
00FF               0 00FD            0   ... Split
0DF5               0 0DA5            0   ..X Synchronized
0DF5               0 0DA4            0   ..X Synchronized
0F70               0 001B         3592   X.. SyncInProg
0F71               0 001C         4496   X.. SyncInProg
0F93               0 0DF9            0   ..X Split
1015               0 1069            0   X.. Synchronized

Total       --------          --------
  Tracks           0              8088
  MB(s)          0.0             505.5

And we are done. As I said this is not a full guide so please if there is anything that you don’t get please leave a comment and I will try to clarify. Also if any of you have additional tips or “recipes” for Timefinder please comment :-)


1 year…

December 7, 2010 — Leave a comment

I really can not believe it but a year has passed since my first “Hello World!” post.

During this first year I received more than 25,000 visits, which to be sincere is far more than I expected. Below is a screenshot showing my top ten posts.

I want to thank all of you who have been following the blog. I also have a special thank to my dear friend Jean Mesquida who have been giving me a lot of feedback about many of my blog posts. I enjoyed to write every post.

I’m pretty sure the next year will be even better.


This post will outline the necessary steps to create a standard (no-multisite) HP P4000 cluster with two nodes. Creating a two-node cluster is a very similar process as the one-node cluster described in my first post about P4000 systems.

The cluster is composed by:

  • 2 HP P4000 Virtual Storage Appliances
  • 1 HP P4000 Failover Manager

The Failover Manager, or FOM, is a specialized version of the SAN/iQ software. It runs as a virtual appliance in VMware, thought the most common situation is to run it in a ESX/ESXi servers running it under VMware player or Server is also supported.

The FOM integrates into a management group as a real manager and is intended only to provide quorum to the cluster, one of its main purposes is to provide quorum in Multi-site clusters. I decided to use it in this post to provide an example as real as possible.

To setup this cluster I used virtual machines inside VMware Workstation, but the same design can also be created with physical servers and P4000 storage systems.

From the Getting started screen launch the clusters wizard.


Select the two P4000 storage systems and enter the name of the Management Group

During the group creation will ask to create a cluster, choose the two nodes as members of the cluster, will add the FOM later, and assign a name to the cluster.

Next assign a virtual IP address to the cluster.

Enter the administrative level credentials for the cluster.

Finally the wizard will ask if you want to create volumes in the cluster, I didn’t take that option and finished the cluster creation process. You can also add the volumes later as I described in one of my previous posts.

Now the that cluster is formed we are going to add the Failover Manager.

It’s is important that the FOM requires the same configuration as any VSA as I depicted in my first post about the P4000 storage systems.

In the Central Management Console right-click into the FOM and select Add to existing management group.

Select the management group and click Add.

With this operation the cluster configuration is done. If everything went well in the end you should have something like this.


Getting the multipathing policy using PowerCLI is a very simple an straight-forward process that can be done with a few commands.

I test this procedure in the past with ESX/ESXi 3.5 and 4.0.

Get the multipahing policy

[vSphere PowerCLI] C:\> $h = get-vmhost esx01.mlab.local
[vSphere PowerCLI] C:\> $hostview = get-view $
[vSphere PowerCLI] C:\> $storage = get-view $hostView.ConfigManager.StorageSystem
[vSphere PowerCLI] C:\> $storage.StorageDeviceInfo.MultipathInfo.lun | select ID,Path,Policy

Id → → Path → → → → Policy
-- → → ---- → → → → ------
vmhba0:0:0 → {vmhba0:0:0} → → → VMware.Vim.HostMultipathInfoFixedLogicalUnitPolicy
vmhba1:1:0 → {vmhba1:1:0, vmhba1:0:0} → VMware.Vim.HostMultipathInfoFixedLogicalUnitPolicy
vmhba1:0:5 → {vmhba1:1:5, vmhba1:0:5} VMware.Vim.HostMultipathInfoFixedLogicalUnitPolicy
vmhba1:0:1 → {vmhba1:1:1, vmhba1:0:1} → VMware.Vim.HostMultipathInfoFixedLogicalUnitPolicy
vmhba1:0:12 → {vmhba1:1:12, vmhba1:0:12} → VMware.Vim.HostMultipathInfoFixedLogicalUnitPolicy

Change the policy from fixed to round-robin

We are going to change the policy for the LUN 12.

[vSphere PowerCLI] C:\> $lunId = "vmhba1:0:12"
[vSphere PowerCLI] C:\> $storagepolicy = new-object VMware.Vim.HostMultipathInfoLogicalUnitPolicy
[vSphere PowerCLI] C:\> $storagepolicy.policy = "rr"
[vSphere PowerCLI] C:\> $storageSystem.SetMultipathLunPolicy($lunId, $policy)

Finally check the new configuration

If you look closely at the last line will see that the value has change from VMware.Vim.HostMultipathInfoFixedLogicalUnitPolicy to VMware.Vim.HostMultipathInfoLogicalUnitPolicy.

[vSphere PowerCLI] C:\> $h = get-vmhost "ESXIPAddress"
[vSphere PowerCLI] C:\> $hostview = get-view $
[vSphere PowerCLI] C:\> $storage = get-view $hostView.ConfigManager.StorageSystem
[vSphere PowerCLI] C:\> $storage.StorageDeviceInfo.MultipathInfo.lun | select ID,Path,Policy

Id → → Path → → → → Policy
-- → → ---- → → → → ------
vmhba0:0:0 → {vmhba0:0:0} → → → VMware.Vim.HostMultipathInfoFixedLogicalUnitPolicy
vmhba1:1:0 → {vmhba1:1:0, vmhba1:0:0} → VMware.Vim.HostMultipathInfoFixedLogicalUnitPolicy
vmhba1:0:5 → {vmhba1:1:5, vmhba1:0:5} VMware.Vim.HostMultipathInfoFixedLogicalUnitPolicy
vmhba1:0:1 → {vmhba1:1:1, vmhba1:0:1} → VMware.Vim.HostMultipathInfoFixedLogicalUnitPolicy
vmhba1:0:12 → {vmhba1:1:12, vmhba1:0:12} → VMware.Vim.HostMultipathInfoLogicalUnitPolicy


As a small follow-up to yesterday’s post about NFS shares with Openfiler in the following article I will show how to add a new datastore to an ESX server using the vMA and PowerCLI.

– vMA

From the vMA shell we are going to use the command vicfg-nas. To clarify things a bit for teh newcomers, vicfg-nas and esxcfg-nas are the same command, in fact esxcfg-nas is no more than a link to the first.

The option to create a new datastore is -a and additionally the address/hostname of teh NFS servers, the share and a label for teh new datastore must be provided.

[vi-admin@vma ~][esx01.mlab.local]$ vicfg-nas -l
No NAS datastore found
[vi-admin@vma ~][esx01.mlab.local]$ vicfg-nas -a -o openfiler.mlab.local -s /mnt/vg_nfs/lv_nfs01/nfs_datastore1 nfs_datastore1
Connecting to NAS volume: nfs_datastore1
nfs_datastore1 created and connected.
[vi-admin@vma ~][esx01.mlab.local]$

When the operation is done you can check the new datastore with vicfg-nas -l.

[vi-admin@vma ~][esx01.mlab.local]$ vicfg-nas -l
nfs_datastore1 is /mnt/vg_nfs/lv_nfs01/nfs_datastore1 from openfiler.mlab.local mounted
[vi-admin@vma ~][esx01.mlab.local]$

– PowerCLI

In the second part of the post we are going to use vSphere PowerCLI, which as you already know is a PowerShell snapin to manage vSphere/VI3 infrastructure. I will write more about PowerCLI in the since I’m very fond with it.

The cmdlet to create the new NFS datastore is New-Datastore and you must provide the ESX host, the NFS server, the path of the share and a name for the datastore. Then you can check that the new datastore has been properly added with Get-Datastore.