22 January 2015

DRSRule - New PowerShell Module for DRS Rule and Group Management

DRS Things
There's a new PowerShell module out, and it is for handling your DRS rule- and group needs!  "Hello, DRS rule/group export and import?  It's me, the new DRSRule module!"  The "why" and the "hows" about the module are further below in this post.

<vNugglets_note> I got to work with the PowerCLI master, Luc Dekens, on this module -- what a treat! (Check out his post about the new module at http://lucd.info/drsrule-drs-rules-and-groups-module)  It was a great learning experience for me, not only on the PowerShell/PowerCLI tip, but also on topics like collaborative/concurrent development, GitHub features (organizations, releases, etc.), and more.

The cmdlets from the module are solid as one would expect:  pipeline support, value by object or name, WhatIf support, and so on.  As for using some of the cool features of PowerShell, the module includes things like advanced/custom type support (including enabling tab-completion of properties later in the pipeline; handy), XML-based external help as manufactured by https://pscmdlethelpeditor.codeplex.com/, and leveraging other object storage formats so as to simplify handling/export/import of rich objects (via JSON) -- just a few of the great features/bonuses by Mr. Dekens. </vNugglets_note>

Now, more about the module.

Why the DRSRule module?

The core PowerCLI PSSnapin from VMware allows for many of the DRS rule operations that one might want to perform.  There have been questions over the years in the VMware Communities PowerCLI forum about how to export DRS rules and groups, and, on how to then import such items.

While there are several posts on the web about how to get/export such things, importing/recreating DRS rules/groups from such exported data has not received much focus.  This was the spark for this DRSRule module:  to allow for easy export/import of such rules/groups.  As part of making a module to handle these actions, other cmdlets were born, like the Get-/New-/Remove-/Set-* cmdlet sets for DRS VM groups and VMHost groups, along with sets for DRS VM to VM rules and VM to VMHost rules.

How to use the DRSRule module?

The DRSRule module comes with an about_DRSRule.
Once the module is installed, use that help topic to get a general introduction to the use of the DRSRule module:
Get-Help about_DRSRule

How to get the DRSRule module?

The source for this PowerShell module is hosted on GitHub.com.
The repository is managed by the GitHub organization "PowerCLIGoodies", and the repo itself is at https://github.com/PowerCLIGoodies/DRSRule.

There are a few ways to get the module, and use it in your PowerShell session:

    Automated

    Via a script
    Use a PowerShell script to perform the download and the extract.
    The script is included in the repository as file DownloadLatest.ps1.

    Via PsGet
    If you have the PsGet module loaded in your PowerShell session, then installing this DRSRule module is as simple as updating PsGet and then installing DRSRule:
    Update-Module -Verbose -Module PsGet
    Install-Module DRSRule

    Manual

    Grab the .zip file of the latest release from the GitHub repository.
    Extract the content to a suitable folder.

    You can go for the Modules folder linked to the Windows account you are using.  To find this path, run:
    Join-Path ${env:\userprofile} "Documents\WindowsPowerShell\Modules"

    Or, you can select any other folder you desire.

    Either way you will end up with a folder named [PathToModule]\DRSRule, in which the PowerShell files for the DRSRule module reside.

    Then, load the DRSRule module into your session:
    If you selected one of the folders in $env:PSModulePath (your PSModule path), you can do this with
    Import-Module DRSRule

    If you picked another folder, you should use the full path to the folder that contains the module's files, like:
    Import-Module [PathToModule]\DRSRule

    Please also read the note below about using Unblock-File, since this module is not Authenticode signed

Note on Unblock-File

This section pertains to using the Manual method above to get the DRSRule module (downloading .zip file).  Since there is no Authenticode certificate supplied for this module, and, assuming that one's PowerShell ExecutionPolicy is at least RemoteSigned, below is a quick/easy way to unblock files.  But, this should only be done when you trust the code in the files that you are unblocking -- inspecting the files is for your own good.
Get-ChildItem [PathToModule]\DRSRule | Unblock-File

06 December 2014

Get VMs' Current EVC Mode via PowerCLI

EVC Mode
Need to report on what is the current EVC mode in which some VMs are running?  We recently did, and out popped a bit of PowerShell/PowerCLI code to do it, of course. As part of some migrations and retirements, we were moving VMs from clusters at one EVC mode (lower) to clusters with higher- or no EVC mode, but were not scheduling power-cycles for the VMs at migration time, so as to keep smaller the scope of work for that event.  Rather than have to keep track of "here are the X number of VMs that are at EVC mode [low]", which would need power-cycled at some later date to bring them up to the EVC mode of their new cluster, PowerCLI is there for us.
It is pretty straightforward, but is handy for identifying those VMs that are, say, at a different EVC mode than is configured on the cluster.  So, the code:
function Get-VMEVCMode {
    <#  .Description
        Code to get VMs' EVC mode and that of the cluster in which the VMs reside.  May 2014, vNugglets.com
        .Example
        Get-VMEVCMode -Cluster myCluster | ?{$_.VMEVCMode -ne $_.ClusterEVCMode}
        Get all VMs in given clusters and return, for each, an object with the VM's- and its cluster's EVC mode, if any
        .Outputs
        PSCustomObject
    #>
    param(
        ## Cluster name pattern (regex) to use for getting the clusters whose VMs to get
        [string]$Cluster_str = ".+"
    )

    process {
        ## get the matching cluster View objects
        Get-View -ViewType ClusterComputeResource -Property Name,Summary -Filter @{"Name" = $Cluster_str} | Foreach-Object {
            $viewThisCluster = $_
            ## get the VMs Views in this cluster
            Get-View -ViewType VirtualMachine -Property Name,Runtime.PowerState,Summary.Runtime.MinRequiredEVCModeKey -SearchRoot $viewThisCluster.MoRef | Foreach-Object {
                ## create new PSObject with some nice info
                New-Object -Type PSObject -Property ([ordered]@{
                    Name = $_.Name
                    PowerState = $_.Runtime.PowerState
                    VMEVCMode = $_.Summary.Runtime.MinRequiredEVCModeKey
                    ClusterEVCMode = $viewThisCluster.Summary.CurrentEVCModeKey
                    ClusterName = $viewThisCluster.Name
                })
            } ## end foreach-object
        } ## end foreach-object
    } ## end process
} ## end function

And, some examples: Get EVC mode info for all of the VMs in this cluster:
PS vN:\> Get-VMEVCMode -Cluster myCluster
Name                   PowerState   VMEVCMode        ClusterEVCMode   ClusterName
----                   ----------   ---------        --------------   -----------
somesvr01.dom.com       poweredOn   intel-westmere   intel-westmere   OurCluster
somesvrlm1.dom.com      poweredOn   intel-penryn     intel-westmere   OurCluster
somesvrbs03.dom.com    poweredOff                    intel-westmere   OurCluster
somesvrxp.dom.com       poweredOn   intel-penryn     intel-westmere   OurCluster
...


For all of the VMs in this cluster where their EVC mode does not match the config'd cluster EVC mode, return their info:
PS vN:\> Get-VMEVCMode -Cluster myCluster | ?{($_.VMEVCMode -ne $_.ClusterEVCMode) -and ($_.PowerState -eq "poweredOn")}
Name                   PowerState   VMEVCMode      ClusterEVCMode   ClusterName
----                   ----------   ---------      --------------   -----------
somesvrlm1.dom.com      poweredOn   intel-penryn   intel-westmere   OurCluster
somesvrp83.dom.com      poweredOn   intel-penryn   intel-westmere   OurCluster
somesvra.dom.com        poweredOn   intel-merom    intel-westmere   OurCluster
...


Note:  The function does expect that you are using at least PowerShell v3, which surely everyone is well beyond by now, anyway.  But, if not, the "[ordered]" cast should be the only thing one would need to take out in order to use in older PowerShell versions.

Straightforward, and uses everyone's favorite PowerCLI cmdlet, Get-View, so you know that it is FaF!  Enjoy.

30 November 2014

XtremIO PowerShell Module Updated -- v0.7.0 available

XtremIO + PowerShell!Even more updates!  Version 0.7.0 of the XtremIO.Utils PowerShell module is now available.  This release brings some great new features, like superior handling of credentials (via new Connect-XIOServer and Disconnect-XIOServer cmdlets), the rest of the New-XIO* cmdlets for creating items in the XtremIO configuration, and new performance-related cmdlets for focusing in on XtremIO performance reporting from several different aspects.

You can read about the new features available in each updated release in the docs in the repo at https://github.com/mtboren/XtremIO.Utils. We have also made a new general information page for this PowerShell module (like how to get it, how to install it, credentials handling). One can find this info page in the Sticky Posts section at the right, too. Or, if you just want at the module immediately, you can download it from https://github.com/mtboren/XtremIO.Utils/releases/download/Latest/XtremIO.Utils.zip.
Once you have read those items, let us get to some examples!

Connect to a couple of XMS servers:
PS vN:\> Connect-XIOServer -Credential $credMe -ComputerName somexms01.dom.com,somexms02.dom.com -TrustAllCert

ComputerName             ConnectDatetime               Port
------------             ---------------               ----
somexms01.dom.com        11/30/2014 1:54:02 PM         443
somexms02.dom.com        11/30/2014 1:54:02 PM         443

Note: this allows for the rest of the subsequent XIO cmdlet calls to be used without presenting credentials again to the cmdlet -- the cmdlets will use the given XIO connection(s) and corresponding connection credentials! Yes, that also means that you need not supply the XMS name each subsequent call: the default, connected XMS servers will be used, unless otherwise specified by the user.

Get the cluster performance information for all XIO clusters managed by the XMS servers:
PS vN:\> Get-XIOClusterPerformance

Name        WriteBW_MBps   WriteIOPS    ReadBW_MBps   ReadIOPS   BW_MBps      IOPS     TotWriteIOs  TotReadIOs
----        ------------   ---------    -----------   --------   -------      ----     -----------  ----------
somexms01   6.057          771          41.768        531        47.824       1302     4664182545   3886061537
somexms02   67.480         2783         238.808       5286       306.288      8069     31163303937  81948491968

Create a new initiator in initiator group "myserver0" on array managed by "somexms02":
PS vN:\> New-XIOInitiator -Name myserver0-hba2 -InitiatorGroup myserver0 -PortAddress 0x100000000000ab56 -ComputerName somexms02.dom.com

Name                   PortAddress                   PortType              IOPS
----                   -----------                   --------              ----
myserver0-hba2         10:00:00:00:00:00:ab:56       fc                    0

Create a new LUN maps on array managed by "somexms02":
PS vN:\> New-XIOLunMap -Volume myVolume02 -InitiatorGroup myserver0,myserver1 -HostLunId 50 -ComputerName somexms02.dom.com

VolumeName          LunId           InitiatorGroup           tg-name
----------          -----           --------------           -------
myVolume02          50              myserver0                Default
myVolume02          50              myserver1                Default

A couple of Get-XIOEvent examples:
PS vN:\> Get-XIOEvent

EventID  DateTime               Severity     EntityDetails      Description
-------  --------               --------     -------------      -----------
2267     11/30/2014 10:39:29 PM information  myVolume02 [1]     Mapped LUN 50 to Volume myVolume02 TG Defa...
2266     11/30/2014 10:39:29 PM information                     User: vNuggsUser, Command: maplun, Argumen...
...
27672    11/30/2014 1:37:41 PM  information  someVolume03       Small block (blocks smaller than 4KB) IO r...
27671    11/30/2014 1:17:05 PM  information                     External user 'vNuggsUser' authenticated w...
...


PS vN:\> Get-XIOEvent -Category activity -Severity information -EntityType BatteryBackupUnit -Start "11 oct 2014" -End "14 nov 2014 8am"

EventID  DateTime               Severity     EntityDetails   Description
-------  --------               --------     -------------   -----------
195      11/11/2014 9:29:30 PM  information  X2-BBU [2]      Added new Battery Backup Unit - UPS[2] "X2-BB...
193      11/11/2014 9:29:30 PM  information  X1-BBU [1]      Added new Battery Backup Unit - UPS[1] "X1-BB...

While it was quite a bit of doing to make this release happen, the new features are well worth it, and it was quite fun along the way. Now to keep the creativity flowing: on to the next update, in which better pipeline support is one of the targets. Until then, enjoy!

XtremIO.Utils PowerShell Module General Info

XtremIO + PowerShell!Herein lies much of the supporting/side information about this PowerShell module that has been written throughout the related vNugglets posts.  The intention, however, is to create this more central spot for this info, instead of people having to sift through the previous posts to get all of these tidbits. To read about the latest additions and changes, one can refer to the change log and the ReadMe (which are available in the module itself, too).
* Update 15 Nov 2015:
Updated links to changelog and readme to be to GitHub, as well as the link to the PowerShell module itself
* end of 15 Nov 2015 update

Module availability:

One can get the XtremIO.Utils module in a couple of ways:
  • via the supercool module PsGet, so installing/updating the module becomes a snap for PsGet module users.  The quick how-to on using PsGet to install the XtremIO.Utils module:
    PS vN:\> Install-Module -Verbose -Module XtremIO.Utils
    
    
    Or, to update the existing version you may already have:
    PS vN:\> Update-Module -Verbose -Module XtremIO.Utils
    
    
  • Or, if you like the "old fashioned" module management route (of manually handling the module grab), you can always follow the steps:
    1. download from latest and greatest! https://github.com/mtboren/XtremIO.Utils/releases/download/Latest/XtremIO.Utils.zip
    2. unzip somewhere you like (like, say, in Join-Path ${env:\userprofile} "Documents\WindowsPowerShell\Modules")
    3. you should now have a folder named <pathToModules>\XtremIO.Utils, in which the PowerShell files reside (see note below about using Unblock-File, since this module is not yet Authenticode signed)
    4. Import-Module <pathToModules>\XtremIO.Utils

Unblock-File discussion:

One of the other "features" of this module:  we have not yet set the Authenticode signature for it.  That is, it is unsigned.  We went back and forth on the solution:
  • buy a legit cert for code signing (best solution, but $$$)
  • sign it with a self-signed cert (which still leads to a prompt of 'Do you want to run software from this untrusted publisher?' when you try to import the module, since everyone is security-minded and has at least the RemoteSigned execution policy set on their machines)
  • ✔ do not add a signature, and make mention that you will need to Unblock-File the files in the module (after careful inspection of the files to make sure that there is nothing dangerous in there; but, we're talking about vNugglets, here -- you can trust us, right?!  a:  No.  Trust no one)
So, since we went with the last option there, below is the quick/easy way to unblock files.  But, again, this should only be done when you trust the code in the files that you are unblocking -- inspecting the files is for your own good.  Anyway, the unblock command:
PS vN:\> Get-ChildItem <pathToModules>\XtremIOInfo | Unblock-File


Credentials discussion:

Credentials come into play in a couple of ways in this module.  One can use the New-XIOStoredCred cmdlet to store one credential persistently on disk.  And, the use of the Connect-XIOServer cmdlet holds credentials in a variable, only for the duration of the PowerShell session (and, only while connected to any XIO servers).

Stored credentials are encrypted using the Windows Data Protection API, via a derivative of HalR9000's Export-PSCredential.  If the encrypted credential file is found at runtime of any of the module's functions that require credentials, the credentials will be imported from said file transparently.

Decryption of the encrypted credentials can only be performed by the user account that performed the encryption, and on the same computer on which the encryption was performed.  This module stores the credential file in the ${env:temp} directory by default, and this location is configurable as desired.

If no credentials are specified to the functions of this module, the given function will look for the credential file in the configured location.  If none exists, the functions behave as before:  they will prompt for credentials as necessary.  And, you can get the stored credential with Get-XIOStoredCred, and remove it from disk, if you would like, with Remove-XIOStoredCred.

30 October 2014

XtremIO PowerShell Module Updated -- v0.6.0 available!

XtremIO + PowerShell!Oh, boy -- more updates!  I committed the module at version 0.6.0 on 24 Sep 2014, and am just now making the time to post about it.  Plenty of good stuff in this release, with some preparation for changes to come. The release notes and change log are in the repo, of course, at https://github.com/mtboren/XtremIO.Utils, but some of the highlights:
  • added explicit Get-XIO* cmdlets for object types, in place of using -ItemType on the Get-XIOItemInfo cmdlet, so as to make things more PowerShell-y
  • more properties available, including loads of performance-related items in a new PerformanceInfo property for many objects
  • added support for new things available in the XIOS v3.0 release (properties, object types)
And, I recently added XtremIO.Utils as a module available via PsGet, so installing/updating the module becomes a snap for PsGet module users.  The quick how-to on using PsGet to install the XtremIO.Utils module:
PS vN:\> Install-Module -Verbose -Module XtremIO.Utils

Or, to update the existing version you may already have:
PS vN:\> Update-Module -Verbose -Module XtremIO.Utils

Or, if you like the "old fashioned" module management route (of manually handling the module grab), you can always follow the steps outlined in our previous XtremIO post here.

And, a couple of futures, in development for the next version of this module:
  • Connect-XIOServer / Disconnect-XIOServer, so as to handle credentials at a connection level instead of a per-call for every cmdlet
  • more New-XIO* cmdlets
In the meantime, enjoy!

30 July 2014

XtremIO PowerShell Module Updated -- Now with New-XIO* Functions!

XtremIO + PowerShell!Since releasing the XtremIO PowerShell module that had "Get" capabilities (about which you can read in our previous XtremIO + PowerShell post, if you missed it), we've been working to improve the module!  Some such improvements:
  • added functions to cover New-XIO* activities, for things like volumes and initiator groups (yes, with -WhatIf)
  • added credential storing, so that you need not specify credentials for every call
  • expanded Get-XIOItemInfo to support more object types (as the API has expanded), like volume folders, initiator group folders, target groups, and bricks
  • updated numeric properties on return objects to actually be numeric (were returned as strings, previously)
  • added function to open the Java GUI (most of the time, "yuck", but, sometimes useful)
  • changed the module name to XtremIO.Utils, as it now does more than reporting information
In the works:  making module available via PsGet, so that it is that much easier to get.  I shall update this post once this is done.

* Update 28 Oct 2014:
Made the time to make this module available via the extra-cool PsGet.  In order to install the XtremIO.Utils module via PsGet's Install-Module:
PS vN:\> Install-Module -Verbose -Module XtremIO.Utils

That's it -- no muss, no fuss!  And, have a look at the PsGet page to see the easy, one-line install of the PsGet module itself if you do not already use it.
End of update - 28 Oct 2014

Now, how about some examples?  Sure!

Create an encrypted, stored credential, that the functions in this module will use by default (so you need not specify credentials for every command):
PS vN:\> New-XIOStoredCred
Windows PowerShell credential request.
Enter credentials to use for XtremIO access
User: mattXio
Password for user mattXio: *********************

VERBOSE: Credentials encrypted (via Windows Data Protection API) and saved to:
'C:\Users\Matt\AppData\Local\Temp\xioCred_by_Matt_on_VM-MattDesktop-002.enc.xml'

Create a new volume:
PS vN:\> New-XIOVolume -ComputerName myxms0.dom.com -Name testvol3 -SizeGB 5120 -ParentFolder "/testVols"

Name        NaaName   VolSizeTB   IOPS
----        -------   ---------   ----
testvol3              5.00        0

Note: there is no NaaName value at this piont, as the NaaName property does not get populated in the volume object until the volume has been mapped to an initiator group for the first time

Create a new initiator group:
PS vN:\> New-XIOInitiatorGroup -ComputerName myxms0.dom.com -Name testIG0 -ParentFolder "/testIGs" -InitiatorList @{"myserver-hba2" = "10:00:00:00:00:00:00:F4"; "myserver-hba3" = "10:00:00:00:00:00:00:F5"}

Name     Index   NumInitiator   NumVol   IOPS
----     -----   ------------   ------   ----
testIG0  21      2              0        0

Create a new initiator group for each host in a cluster:
PS vN:\> ## general params to use for each New-XIOInitiatorGroup call
PS vN:\> $hshGeneralParamsForNewXioIG = @{
    Computer = "myxms0.dom.com"
    TrustAllCert = $true
    Port = 443
    WhatIf = $true
} ## end hashtable

PS vN:\> ## get the HBA WWNs for the VMHosts in the given cluster, and for each VMHost, create a new XtremIO initiator group with initiators for each HBA
PS vN:\> Get-Cluster -Name myCluster0 -PipelineVariable cluThisOne | Get-VMHostHBAWWN | Group-Object -Property @{e={$_.VMHostName.Split(".")[0]}} | Foreach-Object{
    $strVMHostShortname = $_.Name
    ## make a hashtable of key/value pairs that are initiator-name => HBA WWN; initiator names will be like "myhost0-hba2"
    $_.Group | Foreach-Object -begin {$hshInitList = @{}} {$hshInitList["${strVMHostShortname}-$($_.DeviceName.Replace("vmhba","hba"))"] = $_.HBAPortWWN}
    ## make a hashtable of parameters specific to this new initiator group to make
    $hshParamForNewXioIG = @{
        Name = $strVMHostShortname
        InitiatorList = $hshInitList
        ParentFolder = "/$($cluThisOne.Name)"
    } ## end hashtable
    ## create the new initiator group via the given params
    New-XIOInitiatorGroup @hshGeneralParamsForNewXioIG @hshParamForNewXioIG
} ## end foreach-object

Name      Index   NumInitiator   NumVol   IOPS
----      -----   ------------   ------   ----
myhost0   21      2              0        0
myhost1   22      2              0        0
...

This creates an initiator group for each VMHost in the given cluster, each group with an initiator for each of the VMHost's HBAs.  Utilizes the vNugglets function Get-VMHostHBAWWN that we posted in Get VMHost FC HBA WWN Info Most Quickly.  These initiator groups are created in the existing initiator-group folder that is defined for this cluster (of the same name as the cluster).

Open the management console (Java GUI):
PS vN:\> Open-XIOMgmtConsole myxms0.dom.com


Credentials discussion:
Stored credentials are encrypted using the Windows Data Protection API, via a derivative of HalR9000's Export-PSCredential.  If the encrypted credential file is found at runtime of any of the module's functions that require credentials, the credentials will be imported from said file transparently.

Decryption of the encrypted credentials can only be performed by the user account that performed the encryption, and on the same computer on which the encryption was performed.  This module stores the credential file in the ${env:temp} directory by default, and this location is configurable as desired.

If no credentials are specified to the functions of this module, the given function will look for the credential file in the configured location.  If none exists, the functions behave as before:  they will prompt for credentials as necessary.  And, you can get the stored credential with Get-XIOStoredCred, and remove it from disk, if you would like, with Remove-XIOStoredCred.

To use the module, just:  (also, updated above:  install this module via PsGet. See update at top of post)
  1. download from latest and greatest! https://github.com/mtboren/XtremIO.Utils/releases/download/Latest/XtremIO.Utils.zip
  2. unzip somewhere you like (like, say, in Join-Path ${env:\userprofile} "Documents\WindowsPowerShell\Modules")
  3. you should now have a folder named <pathToModules>\XtremIO.Utils, in which the PowerShell files reside (see note in previous XtremIO + PowerShell post about using Unblock-File, since this module is not yet Authenticode signed)
  4. Import-Module <pathToModules>\XtremIO.Utils

Other upcoming changes:
  • add the other New-XIO* functions for things like folders, single initiators, lun-maps, more
  • expand Get-XIOItemInfo to support even more object types (as the API continues to expand), like volume snapshots, events, dataprotection-groups
  • actually get the project on GitHub
Enjoy, and let us know what features would be best to add the soonest!

* Update 06 Aug 2014:  included the MIT License file in the .zip file.

17 July 2014

Get VMHost FC HBA WWN Info Most Quickly with PowerCLI

VMHba WWN Info
People know about getting VMHost HBA info via PowerCLI -- there are plenty of posts about doing so, generally via Get-VMHostHba.  Since that works great, there is barely a reason to write something else to do the same thing, save one reason that is near and dear to our vNugglets hearts:  speed.  We made this a couple of years ago, have tweaked it a few times, and now it seems like time to post it (like, maybe it will be helpful in an upcoming post, or something?  So exciting).

This function uses everybody's favorite PowerCLI cmdlet Get-View.  The speed reward:  well worth it.  For example:
Technique
Time, 28 hosts
Time, 270 hosts
Get-VMHostHba
61.9s
720s
Get-VMHostHBAWWN
1.32s
14.1s
improvement:
46x
51x

More than 45 times faster?  I'm in.  Now for the function, complete with examples in comment-based help:  (double-click anywhere in the code to Select All)
function Get-VMHostHBAWWN {
<#    .Description
    Get the Port- and Node WWN(s) for HBA(s) in host(s). Feb 2012, vNugglets
    .Example
    Get-VMHostHBAWWN -VMHost myhost0.dom.com
    VMHostName       DeviceName  HBAPortWWN               HBANodeWWN               HBAStatus
    ----------       ----------  ----------               ----------               ---------
    myhost0.dom.com  vmhba1      10:00:00:00:00:00:00:ca  20:00:00:00:00:00:00:ca  online
    myhost0.dom.com  vmhba2      10:00:00:00:00:00:00:83  20:00:00:00:00:00:00:83  online
    Get the HBA WWNs for hosts whose name match the pattern myhost0.dom.com
    .Example
    Get-VMHostHBAWWN -VMHost ^my.+
    VMHostName       DeviceName  HBAPortWWN               HBANodeWWN               HBAStatus
    ----------       ----------  ----------               ----------               ---------
    myhost0.dom.com  vmhba1      10:00:00:00:00:00:00:ca  20:00:00:00:00:00:00:ca  online
    myhost0.dom.com  vmhba2      10:00:00:00:00:00:00:83  20:00:00:00:00:00:00:83  online
    mytest1.dom.com  vmhba1      10:00:00:00:00:00:00:da  20:00:00:00:00:00:00:da  online
    mytest0.dom.com  vmhba2      10:00:00:00:00:00:00:93  20:00:00:00:00:00:00:93  online
    Get the HBA WWNs for hosts whose name match the pattern ^my.+
    .Example
    Get-Cluster mycluster | Get-VMHostHBAWWN
    ...
    Get the HBA WWNs for hosts in the cluster "mycluster"
    .Outputs
    PSCustomObject
#>
[CmdletBinding()]param(
    ## Name pattern of the host for which to get HBA info (accepts regex patterns)
    [parameter(Mandatory=$true,ParameterSetName="SearchByHostName")][string]$VMHostName_str,
    ## Name pattern of the cluster for whose hosts to get HBA info (accepts regex patterns)
    [parameter(Mandatory=$true,ParameterSetName="SearchByCluster",ValueFromPipelineByPropertyName)][Alias("Name")][string]$ClusterName_str
) ## end param
Begin {
    ## helper function for formatting WWN as hex string with colon-separators
    function _Format-AsHexWWNString {
        param([parameter(Mandatory=$true)][long]$WWN_long)
        (("{0:x}" -f $WWN_long) -split "(\w{2})" | ?{$_ -ne ""}) -join ":"
    } ## end function
}

Process {
    ## params for the Get-View expression for getting the View objects
    $hshGetViewParams = @{
        ViewType = "HostSystem"
        Property = "Name", "Config.StorageDevice.HostBusAdapter"
    } ## end hashtable
    Switch ($PSCmdlet.ParameterSetName) {
        ## if host name pattern was provided, filter on it in the Get-View expression
        "SearchByHostName" {$hshGetViewParams["Filter"] = @{"Name" = $VMHostName_str}; break;} ## end case
        ## if cluster name pattern was provided, set it as the search root for the Get-View expression
        "SearchByCluster" {$hshGetViewParams["SearchRoot"] = (Get-Cluster $ClusterName_str).Id; break;}
    } ## end switch

    Get-View @hshGetViewParams | Foreach-Object {
        $viewHost = $_
        $viewHost.Config.StorageDevice.HostBusAdapter | Where-Object {$_ -is [VMware.Vim.HostFibreChannelHba]} | Foreach-Object {
            New-Object -TypeName PSObject -Property ([ordered]@{
                VMHostName = $viewHost.Name
                DeviceName = $_.Device
                HBAPortWWN = _Format-AsHexWWNString -WWN $_.PortWorldWideName
                HBANodeWWN = _Format-AsHexWWNString -WWN $_.NodeWorldWideName
                HBAStatus = $_.Status
            }) ## end new-object
        } ## end foreach-object
    } ## end foreach-object
} ## end process
} ## end function

Not terribly fancy, but something to get it done more quickly (FaF, in fact).  And, handy for other things down the road.  Like, oh, using the WWN info when creating some initiator groups on your XtremIO array?  What a good idea.

Oh, and if you have not yet seen/used parameter splatting, this provides a decent example of that, too -- the hashtable of parameters used on line 54.  Enjoy!