Well, this the end of my 6 part series on storage and vSphere 5.5. There’s is a part that’s “missing” all about “Vendor Storage Plug-ins”. I did some recent work with a vendor before I left the colo… but their software is still under beta at the moment… So there will a be a lost part 7 to release when the embargo ends…
Rescanning Storage
A simple one-liner PowerCLI command is all that is required to rescan many hosts storage configuration – care must be taken not to rescan every single host in vCenter, and limit rescans to clusters of ESX hosts
Get-Cluster -name “NYC-Gold01” | Get-VMhost | Get-VMHostStorage -RescanAllHBA
Configuring iSCSI Storage
This is script uses a .CSV file retrieve the FQDN/Hostname values.
The first block of PowerCLI enables the iSCSI Software Adapter together with a valid IQN, Target IP, Chapname & Password. The second block uses the ESXCLI namespace within PowerShell to set the VMKernel Port Bindings for iSCSI Load-balancing. Finally, a rescan is undertaken to find new storage and VMFS volumes. This script assumes the appropriate networking is in place.
Import-CSV vmhosts.csv | ForEach-Object {
$hostname = $_.vmhost
$shortname = $_.shortname
$target0 = "172.168.3.69"
Get-VMHostStorage -VMHost $hostname | Set-VMHostStorage -SoftwareIScsiEnabled $true
$iscsihba = Get-VMHostHba -VMhost $hostname -Type iScsi
$iscsihba | Set-VMHostHBA -IScsiName iqn.2013-11.com.corp:$shortname
New-IScsiHbaTarget -IScsiHba $iscsihba -Address $target0 -ChapType Required -ChapName vmware -ChapPassword VM@re1
$esxcli = Get-ESXCLI -VMHost $hostname
$esxcli.iscsi.networkportal.add($iscsihba, $true,"vmk1")
$esxcli.iscsi.networkportal.add($iscsihba, $true,"vmk2")
}
Get-VMHostStorage -VMHost $hostname -RescanAllHba
Get-VMHostStorage -VMHost $hostname -RescanVmfs
If your storage vendor supplies load-balancing software – this could be installed using PowerCLI. In this example the Dell MEM is being installed:
Foreach ($vmhost in (get-vmhost))
{
Set-VMHost -VMHost $vmhost -State "Maintenance"
Install-VMHostPatch -VMHost $vmhost -LocalPath "C:\MEM1.2\dell-eql-mem-esx5-1.2.0.365964\metadata.zip" -HostUsername root -HostPassword Password1
Set-VMHost -VMHost $vmhost -State "Connected"
}
Creating VMFS Volumes
Like any process the creation of VMFS volumes using PowerCLI is a viable operation. Clearly care must be taken in enumerating the right LUN/volume to avoid a situation where data loss could occur. This starts at the fabric layer ensuring only LUN/Volumes intended for VMware ESX are presented.
The New-Datastore cmdlet requires the “Canonical Name” parameter in order to format a volume, the Canonical Name is unique ID for block storage. By using the Canonical Name you can guarantee the identity of a given block of storage. Using Get-SCSILun can retrieve storage from a specified ESX host – when combined with filters that show the Vendor, Canonical Name, Capacity and the Runtimename this can assist in locating the correct SCSI disk
Get-SCSILun -VMhost esx01nyc.corp.com -LunType Disk | ?{$_.vendor -eq "NETAPP"} | Select CanonicalName,CapacityGB,runtimename
Get-SCSILun -VMhost esx01nyc.corp.com -LunType Disk | ?{$_.vendor -eq "EQLOGIC"} | Select CanonicalName,CapacityGB,runtimename
In the first example the command returns a single 1.5TB disk with a Host ID of 10. In many environments its possible for the LUN ID on the storage array to be one value (say 23) but the ID as it is known to the host be a different value altogether (for example say 10). For simplicity some administrators make the Host ID and LUN ID the same value to ease identification of the disk.
To return a list of disks that already formatted with VMFS we could use this PowerCLI oneliner:
Get-Datastore | where {$_.type -eq 'vmfs'} | get-view | %{$_.info.vmfs.extent} | select -ExpandProperty diskname
To format this disk with VMFS we would use the Canonical Name of naa.60a980005034484d444a7632584c4e39. The format only needs to be carried out by one VMware ESX host, and then the other hosts in the same cluster can be re-scanned too.
New-Datastore -VMHost esx01nyc.corp.com -Name NETAPPLUN10 -Path naa.60a980005034484d444a7632584c4e39 -Vmfs Get-Cluster -name “NYC-Gold01” | Get-VMhost | Get-VMHostStorage -RescanAllHBA
If you do attempt to re-format a VMFS volume you should receive a message that it is “in use” from PowerCLI
Mounting NFS Volumes
In this case variables are specified for the NFS Target and Volumes to be mounted. By default a maximum of 8 NFS mount points are enabled. This can be increased using the Set-VMHostAdvancedConfiguration cmdlet. The maximum number of supported NFS mounts in ESX 5.5 is 256.
Set-VMHostAdvancedConfiguration -VMHost $vmhost -Name NFS.MaxVolumes -Value 64 -Confirm:$false
$nfshost = "172.168.3.89"
$mount1 = "software"
$mount2 = "templates"
$mount3 = "infrastructureNYC"
Foreach ($vmhost in (get-vmhost))
{
New-Datastore -VMHost $vmhost -Name $mount1 -Nfs -NfsHost $nfshost -Path /vol/$mount1
New-Datastore -VMHost $vmhost -Name $mount2 -Nfs -NfsHost $nfshost -Path /vol/$mount2
New-Datastore -VMHost $vmhost -Name $mount3 -Nfs -NfsHost $nfshost -Path /vol/$mount3
}
Modifying Path Selection Policies
Modifying Path Selection Policies with Set-SCSILun:
As with formatting VMFS volumes we need the Canonical Name to change the default PSP used. Fortunately, its possible to identify different disk/vendor type by the first couple of bytes in the name itself
Get-SCSILun -VMhost esx01nyc.corp.com -LunType Disk | Select CanonicalName,CapacityGB,runtimename,MultiPathPolicy
So in this case here all NetApp FC LUNs are identified by using naa.60a98 whereas the Dell Equallogic Volumes are identified by using naa.6090a. We can use the Set-ScsiLun cmdlet to change the policy to an appropriate settings. For example if ALUA has been enabled and is supported on the NetApp Array we could switch the “Fixed” paths to a “RoundRobin” path like so:
Foreach ($vmhost in (get-vmhost))
{
Get-VMHost $vmhost| Get-ScsiLun -CanonicalName “naa.60a98*” | Set-ScsiLun -MultipathPolicy "roundrobin"
}
Modifying Path Selection Policies with ESXCLI:
In most case this simple script can be used to modify the PSP for all the hosts in a datacenter or cluster depending on the filter type you use. However, there are some case where Set-ScsiLun -Multipathpolicy will not work. This is because it appears to only recognise the built-in PSP provided by VMware. If a new PSP is added by the installation by third party vendor the above PowerCLI will in most cases not work. Additionally, you can also find that Get-ScsiLun can misreport the MultiPathingPolicy
In this situation you can resort to calling ESXCLI from within PowerCLI to achieve the same result. In this case the Dell MEM PSP was set used as an example.
Here esxcli.storage.nmp.device.list is used to locate all the Dell Equallogic Disks beginning with naa.6090sa. This pipelined to the esxcli.storage.nmp.device.set command to change the PSP used. Finally, esxcli.storage.nmp.satp.set is used to set the default PSP for future volumes.
WARNING: The name space around esxcli has change. If you reading other sources you might find that code examples use esxcli..nmp. rather than esxcli.storage.nmp. Additionally, ESX 5.5 introduced new labels for carrying out tasks. For example in ESX 5.5 setting a default PSP is done with esxcli.storage.nmp.set, whereas in previous releases it was done with esxcli.storage.nmp.setpolicy.
Acknowledgement: Arnim van Lieshout post ESXCLI the PowerCLI way provide an invaluable starting point for this section.
Foreach ($vmhost in (get-vmhost)) {
$esxcli = Get-EsxCli -vmhost $vmhost
$esxcli.storage.nmp.device.list() | Where {$_.device -like "naa.6090a*"} | select -Property Device,PathSelectionPolicy | %{
$esxcli.storage.nmp.device.set($null, $_.Device, "DELL_PSP_EQL_ROUTED")
}
$esxcli.storage.nmp.satp.set($null,"DELL_PSP_EQL_ROUTED","VMW_SATP_EQL")
}
To return a list of the volumes and their PSP you can use this script perhaps called StorageESXCLIpaths.ps1 <hostname/fqdn> to return the paths and MEM used…
$vmhost=$args[0]
$esxcli = Get-EsxCli -vmhost $vmhost
$esxcli.storage.nmp.device.list() | Where {$_.device -like "naa.6090a*"} | Select DeviceDisplayName,WorkingPaths,PathSelectionPolicy
Renaming Datastores
A good example of wanting to rename datastore en masse is with local storage. As we saw earlier because all local storage is formatted with with the label “datastore1”, when more than one ESX host is added to vCenter – this can lead to an unsightly and confusing serialization process where volume labels are automatically renamed to be datastore1, datastore1 (1), datastore1 (2). Some SysAdmin prefer to handle this issue with a post-installation script that executes in the context of the ESX host installation – others prefer to use PowerCLI.
We would like to acknowledge Nicolas Farmers www.pcli.me blog from which this script was used as the template – http://www.pcli.me/?p=25
$hostnames = get-vmhost | %{$_.name}
foreach($vmhost in $hostnames)
{
$one1 = $vmhost.split(".")
$two2 = $one1[0]
$thename = $two2+"-local"
get-vmhost $vmhost | get-datastore | where {$_.name -match "datastore1"} | set-datastore -name $thename
}
Creating Datastore Folders
Datastore Folders can be created to separate local storage from remote storage (FC, iSCSI, NFS) or alternatively a folder structure could be created for each cluster created in vCenter.
Local/Remote:
$root = get-folder -type Datastore new-folder -Location $root "Local Storage" new-folder -Location $root "Remote Storage"
By Cluster:
$root = get-folder -type Datastore
foreach($cluster in (get-cluster))
{
new-folder -Location $root $cluster
}
new-folder -Location $root "Local Storage"
Moving Datastores:
Moving datastores to a different folder is easy once you have a meaningful naming convention. It’s somewhat harder if your datastores names are unique, and don’t follow a naming convention. In this simple script all the datastore are dumped into a folder called “Remote Storage”, and then the VMFS volumes which have “local” in their name are relocated to a folder called “Local Storage”.
Move-Datastore -Destination "Remote Storage" Move-Datastore local* -Destination "Local Storage"