VCAP5-DCA Objective 1.3 – Configure and Manage Complex Multipathing and PSA Plug-ins

For this objective I used the following documents:

  • Documents listed in the Tools section

Objective 1.3 – Configure and Manage Complex Multipathing and PSA Plugin-ins



  • Explain the Pluggable Storage Architecture (PSA) layout
    • The Pluggable Storage Architecture (PSA) is a framework that is use for handling multipathing in a VMware environment. The framework is modular so it allows third-party vendors to build their own multipathing plugins and put them directly inline with storage I/O. The PSA is a collection sits at the vmkernel layer and is essentially a collection of vmkernel APIs                                   (image from vSphere Storage Guide)


    • The PSA consists of plug-ins and sub plug-ins and perform different functions
      • Multipathing Plug-in (MPP)
        • These are provided by third-party vendors. An example of of a MPP is EMCs PowerPath/VE. VMware’s Native Multipathing Plug-in is also a MPP
      • Native Multipathing Plug-in (NMP)
        • Path Selection Plug-in (PSP)
          • Determines which active path to use when issuing an I/O request to a storage device
          • If the active path to a particular storage device fails, PSP will determine which path to use next to issue the I/O request
          • Third-party vendors can create and integrate PSPs that run alongside VMware’s PSPs
        • Storage Array Type Plug-ins (SATP)
          • Determines and monitors the physical path states to the storage array
          • Determines when a physical path has failed
          • Activates new physical paths when the active path(s) has failed
          • Perform any other necessary array specific actions required during a storage fail-over
          • Third-party vendors can create and integrate SATPs that run alongside VMware’s SATPs

Skills and Abilities

  • Install and Configure PSA plug-ins
    • Third-party vendors can supply their own MPP, such as EMC PowerPath/VE, or they can supply sub-plugins for PSP or SATP that supplements VMware’s NMP. These plug-ins will come in the form of a bundle and can be installed the following ways:
      • VMware vSphere Update Manager
      • Connected directly to the host via SSH console (use the esxcli software vib install command)
      • Using the vSphere Management Assistant (vMA) using the esxcli software vib install command
      • If the new plugin is not automatically registered you can do so manually
    • If you need to set a new default PSP for a SATP use the following commands:
    • Any devices that are currently using the SATP that you just changed will need to have all of their paths unclaimed and reclaimed. If you want to perform these operations via esxcli you will have to stop all I/O going to these devices, which usually isn’t a possibility. In this case you must reboot the host(s) in order for the new PSP to take effect
    • When you load a third-party SATP into NMP you are doing so in order to use the new SATP with a particular device. Here are the commands to run in order to claim a device under a different SATP – in this example I’m going to change the default SATP for a particular device to another SATP. When you install a third-party SATP the claim rule will most likely be specific to a class of devices and not a device ID, which is what I’m doing here.

  • Understand different multipathing policy functionalities
    • I understand “multipathing policy functionalities” to be the Path Selection Plug-ins, or PSP. If someone has any comments what else this might be referring to, please let me know! VMware KB 1011340 also refers to PSPs as multipathing policies
    • By default there are three PSP’s that ship with vSphere
      • VMW_PSP_MRU
        • The host will use the pat that is most recently used (MRU). When a path fails and another one is activated, the host will continue to use this new active path even when the original path comes back up.
        • Default for active/passive arrays
        • Default for ALUA devices
        • The host will use a fixed path that is either, set as the preferred path by the administrator, or is the first path discovered by the host during the boot process
        • Default for active/active arrays
      • VMW_PSP_RR
        • The host will use all active paths in a round robin (RR) fashion. It uses an algorithm to iterate through all active paths. The default number of I/Os that are issued to a particular path is 1000 before moving on to the next active/available path
        • No default array types are listed for this PSP


  • Perform command line configuration of multipathing options
    • There are a multitude of multipathing options that can be changed using the command line. Some can be changed in the GUI as well, but other settings must be changed via command line
    • In the Install and Configuring PSA Plug-ins I covered how to change the default PSP for a particular SATP, so I won’t go over that again here
    • Changing the PSP on a particular device
    • You can view device configurations for individual devices based on their assigned PSP. The following commands will view the device configurations for devices assigned the RR and Fixed PSPs. There will also be a command that lists the generic device configuration regardless of its assigned PSP
    • You can also set different parameters for PSP with esxcli. The following commands will set the preferred path on a device using VMW_PSP_FIXED and customize different parameters for a device using VMW_PSP_RR
    • You can also make changes to a device configuration using the generic option. Here is an example of changing a device that is using the VMW_PSP_RR plug-in
    • As you can see there are a lot of different things you can change with esxcli and multipathing configuration. Here is a video of performing some of these configurations



  • Change a multipath policy
    • You can change the multipathing policy a either in the GUI or via the command-line. I covered the command-line method in the previous section, Perform command line configuration of multipathing options, so I won’t go over here again. Here is how you change the multipath policy in the GUI
      • Log into the vSphere client > select a host that is connected to the device you want to change the multipathing policy for
      • Click the Configuration tab > click the Storage hyperlink
      • Right-click the datastore you in which you want to modify the multipathing policy for > click Properties…
      • Click the Manage Paths… button


      • From the Path Selection: drop-down select the multipathing policy you want to change it to
      • Click Change   << this is important, if you click the Close button without first clicking Change then the multipathing policy will not be changed


      • Click Close to exit the datastore properties


  • Configure Software iSCSI port binding
    • Prior to vSphere 5 software iSCSI port binding could only be configured via the CLI. With the release of vSphere 5, VMware has made all of our lives easier and added this to the GUI (in the properties of the iSCSI software initiator)
    • Before you begin the port binding process you need to have created 1:1 mappings of vmkernel adapters:physical adapters. This way, we can bind a single vmkernel adapter to a single physical adapter, enabling multipathing. Ensure these steps have been completed:
      • Created as many virtual switches or port groups as the number of physical adapters you will be using for iSCSI
      • You’ve created a vmkernel adapter for each vswitch or port group
      • You changed the NIC Teaming on each vswitch or port group to reflect on one active adapter and no standbys
      • the iSCSI software adapter is enabled and has its targets configured
    • Once you have this done you need to configure port binding. Let’s go through how to do it in the GUI first
      • Log into the vSphere client > select the host for which you are configuring iSCSI port binding on
      • Click the Configuration tab on the right > click the Storage Adapters hyperlink
      • Select the iSCSI software initiator > click the Properties… hyperlink
      • Select the Network Configuration tab > click the Add button


      • Select the vswitch or port group that corresponds with they vmkernel adapter and physical adapter that you have setup for iSCSI


      • Click OK
      • Ensure that the Port Group Policy is appears as Compliant


      • Click Close > click Yes to perform a rescan
    • Now lets do the iSCSI port binding using esxcli
      • Here is the result of the list command, as you can see, vmhba35 and vmk1 are bound



Leave a Reply

Your email address will not be published. Required fields are marked *