J.F.V.I

I’ve recently had to put some documentation together on bringing our patching of ESX hosts into line with patching procedures for other inventory items in our estate. While the actual patching is straight forward, getting data out of the process to show the compliance level of the hosts is not so straight forward.

Yet again , powerCLI to the rescue , with its champion Alan Renouf has discovered that an additional download to the powerCLI package allows us to interrogate VUM , as well as scan and remediate hosts. Hopefully with bribary of a number of beers an external report that I can pass to our security teams with baseline compliance for any number of hosts may well appear on his site soon….

One of the nicer wins for us in vSphere was that Round-Robin multipathing support was taken from experimental to full support. In order to take advantage of this my colleague had a large number of pathing policies to change – something of the order of 700 individual operations if done through the VI Client.

This is of course a big stack of work that’s error prone and something we’d want to avoid. On the previous VI3.5 environment this would have been done with scripting at the service console, however our new environment is based on ESXi – of course we could possibly use The vSphere Management Assistant however I felt there may well be a more elegant solution based on powershell.

Powershell adoption in a team of GUI-Jockeys can be a bit of a challenge but Quest have provided an ideal tool and for free too in the form of the Virtualisation EcoShell Initiative Which compiles a number of powershell scripts into an easy to use interface – it also allows you to import “Powerpacks” of scripts from other Powershell gurus such as  Alan Renouf to do all multitude of actions with your Virtual Infrastructure.

That said , I couldn’t find a way of bringing up the pathing policy for a given datastore on a host. I thought it would be a handy list to have in the VESI window.

A couple of twitter posts  later and a fresh, crisp email from Scott Herold arrived with some neatly written scripts and a how-to , which is below.

First thing to note is that you MUST be using PowerCLI 4.0 Update 1 for these scripts to work.  I didn’t write them with all the Gold 4.0 EcoShell session management requirements.

1)      Once you get connected up to a vCenter server, choose the top-level Hosts node.

2)      Right-Click on the “Links” heading in the Actions pane and choose New -> Script Action

3)      Give it a fancy name at the top like “SCSI LUNs” and paste the following code block into the code window

$input | ForEach-Object {
$vmh = $_.Name
$sl = $_ | Get-ScsiLun
$ds = $_ | Get-Datastore | Get-View
$sl | ForEach-Object {
$assocVMFS = "No VMFS/RDM"
$slcn = $_.CanonicalName
$ds | ForEach-Object {
$vmfs = $_
$_.Info.Vmfs.Extent | ForEach-Object {
if ($_.DiskName -eq $slcn) {
$assocVMFS = $vmfs.Name
}
}
}
$_ `
| Add-Member -MemberType NoteProperty -Name VMHost -Value $vmh -PassThru `
| Add-Member -MemberType NoteProperty -Name AssocVMFS -Value $assocVMFS -PassThru
}
}

4. The above block does a bunch of extra intelligence that applies the Host Name as well as the VMFS mapping, assuming it is mapped to a VMFS.  This is not the case for RDMs or LUNs that have not yet been formatted.
5.Before clicking OK and exiting the code window, Click on the “Display Configuration” button in the top-left corner under the action title bar.
6.Under the “Display Results” section, choose “Display the results in a nested view”.  This will tell EcoShell to use the breadcrumbs across the top so you see your navigation from Hosts -> SCSI LUNs. Failure to do this step will give off the appearance that the script doesn’t work.
7. Once you’ve made the change, Click OK to exit the Configuration Properties and again to save and exit the new script.In the Admin Console, select one or more hosts and choose the new SCSI LUNs link.  You should be returned a list of results

Step 1 is now complete.  You should get a list of SCSI LUNs mapped to the particular Host or Hosts you selected.  You will want to Right-Click on one of the column headings and show some additional columns to add additional value to the view.  My view looks like the following.

You will notice I have columns for Associated VMFS and the VMHost.  These are properties that VMware does NOT apply to the default cmdlet output.  This is where EcoShell shines over standalone console.  You can now export this data view in XML, CSV or HTML and have a report of all multipath policies across all ESX Hosts in your infrastructure.  You can even use filters to highlight and narrow down results that meet a certain criteria, like when MultipathPolicy doesn’t equal RoundRobin.

1. Right Click anywhere in the blank space in the Actions bar on the right side and again choose a new  script action.

2. Give this one a name of “Set Multipath Policy” and paste the following code

switch (Read-Choice 'Mulitpath Policy' 'What would you like the new multipath policy for the selected LUNs to be? (Note, this is a per HOST per LUN setting)' 'Fixed','Round Robin','Most Recently Used' 0) {
0 { $mpPolicy = "Fixed" }
1 { $mpPolicy = "RoundRobin" }
2 { $mpPolicy = "MostRecentlyUsed" }
}

$input | ForEach-Object {
if ($mpPolicy -eq “Fixed”) {
$cn = $_.CanonicalName
$slp = @()
$slp += Get-VMHost $_.VMHost | Get-ScsiLun | where {$_.CanonicalName -eq $cn} | Get-ScsiLunPath
Get-VMHost $_.VMHost | Get-ScsiLun | where {$_.CanonicalName -eq $cn} | Set-ScsiLun -MultipathPolicy “Fixed” -PreferredPath $slp[0]
}
else {
$_ | Set-ScsiLun -MultipathPolicy $mpPolicy
}
}

3. Again, click on the Display Configuration button.  This time, change the dropdown under the “Category” section to be listed under “Actions”.  Click OK Twice to exit to the Admin console and save the new script.  Note, that in the script above, I am creating a user input selection to allow you to choose Fixed, RR, or MRU.  In order to choose Fixed, VMware forces you to select a Preferred Path value, so I have the conditional statement set up to trap the Fixed parameter.  I then have to create a collection object and add each SCSILunPath object to it.  I force create it as a collection $slp = $() so that even if only one object is returned, the set-scsilun command will work against $slp[0], which is just the first path returned in the llist.  Generic and a total cop out, but it works no matter what the situation is.

4. Once you are in the Admin console you can now single or multi-select your SCSI LUN paths armed with the knowledge of what Host they are on and what VMFS they are mapped to in order to make the most educated choices in bulk multipath management….and it’s a HECK of a lot easier than using vCenter.

I worked through Scott’s document this morning and can say it works an absolute treat , will definatly be using it for any pathing changes in the future.

All credit for the script goes to Scott Herald at Quest – I just thought of the idea….