This self paced workshop demonstrated 3 key components of PowerPath: Virtual Multipath Management, Encryption, and Migration Enabler. The presenters for the session were Rob Pellowski, Brian Stultz, and Eddie Thigpen. This H.O.W (Hands on Workshop) was one I was looking forward to. My primary focus was on PowerPath/VE, I spent little time allocated to the other components and their demos due to the lack of time.

As we all know PP/VE will be offered as an add on to both ESX 4.0 and 2008 Hyper-V. Here are some of the notable features:

• Dynamic Load Balancing
• Dynamic path failover and auto recovery
• Device prioritization
• Monitoring and reporting of I/O stats
• Auto restore of paths
• Auto path testing
• ESX cluster support
• Non-EMC array support
• Remote management using vSphere CLI

PP/VE taps in to VMware’s Pluggable Storage Architecture  (PSA). This allows PP to operate within the storage I/O path via VMkernel API’s. PP/VE can coexist with NMP (Native Multi Path) which is used on arrays not supported by PP.

Installation takes place remotely either from a Windows host or a RHEL 5 host using the vihostupdate util (as part of vSphere utility kit?). You do not initiate the installation from the ESX directly. Post installation of PP does require a reboot of the ESX host.

Once the installation is complete and the host is reboot, PP is managed through remote CLI using the rpowermt (powermt equivalent) command set. This allows one to manage and configure PP/VE as well as any paths under its control. Multiple hosts can be managed from a single host simply by specifying the IP or FQDN of that particular host. Chatter between the ESX host and the remote CLI host is via CIM or Common Information Mode). An RSA lockbox stores all creds and other pertinent Info on the RC host. The following are some common command sets with rpowermt tool.

• rpowermt check registration-displays licensing info
• rpowermt config-updates Clariion nice names
• rpowermt display-shows HBA, storage arrays, optimization settings, I/O to name a few for each device
• rpowermt display latency-monitors latency
• rpowermt display options-shows management and auto restoration of paths of all array classes

Other commands without descriptions:

• rpowermt display paths
• rpowermt display ports
• rpowermt register
• rpowermt restore
• rpowermt path_latency_monitor
• rpowermt path_latency_threshold
• rpowermt periodic_autorestore
• rpowermt set policy/set priority/set mode/update lun_names/unregister/version

----Points of Interest----

• Errors represented with the rpowermt display are indicative of the total number of times the path has transitioned from “alive” to “dead”.
• PP will load balance across to paths to a Clariion on the same SP. Therefore it is recommended to have at least 4 paths to the Clariion whether ALUA or PNR mode is in use.
• Only devices managed by PP will have a pseudo name. This name will not be presented in the OS.
• Up to 32 paths are supported for a single device. Load balancing and failover algorithm are optimized according to the array in use.  Available policies are SymmOpt, ClarOpt and Adaptive for third party arrays.
• Generally PP/VE is monitored and managed using the rpowermt command with the remote CLI. vCenter can be used, however, to identify whether a device is owned by PP or NMP. Future, more granular integration is expected.
• PP supports FC, iSCSI and FCoE. Additionally full interop with DRS/VMotion and other layered feature sets.
• PP is VM independent, the guest OS has no knowledge that PP is managing the devices that it lives on.
• PP has a unique position in the I/O stack, right above the HBA but below the filesystems, applications and guest OS’s.