Using PowerShell to prevent thinly provisioned NetApp LUNs from going offline – Part I

Happy Day-after Thanksgiving dear readers! I hope everyone is as satisfyingly full on food, friends, and family as I am.  As an early gift to myself, I’m writing a PowerShell script that utilizes NetApp’s PowerShell Toolkit.  The script will help me quickly determine current volume and LUN settings so I can see what LUNs are at risk of going offline due to out of space conditions.  In scripting tradition, I couldn’t find anything online that did exactly what I wanted so I rolled my own!

Here’s what the output looks like. The column names are abbreviated because I expect to have several more columns. The abbreviations are, Volume Thin Provisioning, Fractional Reserve, Snapshots, Volume AutoGrow, Snapshot AutoDelete.

Volume Best Practices script output

The usefulness of the script can be seen in the highlighted output. The Exchange volumes are thin provisioned, Fractional Reserve is set to 0 for each, Snapshots are on, and space protection settings Volume AutoGrow and Snapshot AutoDelete are not turned on. This tells me I should investigate these volumes and LUNs to be sure they’re configured properly. I would likely want to, at a minimum, turn on Volume AutoGrow and Snapshot AutoDelete.

I expect this script to be extremely useful to our Managed Services team, in particular, as we take on more and more Managed Services clients.  We’ve been bitten more than once by out of space conditions even though we use OnCommand Unified Manager.  When run, the script will allow someone to see, at a glance, which settings are not set according to NetApp’s best practices.

This is Part I of several posts that will show the evolution of this script into its final form.  Earlier this week I brought the script into a minimally usable form which is enough to share with the community.  There’s plenty more to do, no doubt, though.  I have no LUN information, for example.  The sole function does not sanitize inputs, and I’m sure some of the logic could be optimized for speed.  It seems kind of slow right now and I’ve only been testing against FAS2240s.  Either way, here it is in all its glory! Please share your thoughts on how to improve it or perhaps share a script of your own.

In addition, I’ve of course used many ideas from the internets.  So if you see something in here that looks familiar, it’s probably yours :-) Thanks for letting me borrow it.


  • NetApp PowerShell Toolkit
  • Data ONTAP 7-mode
  • Manually log into each controller using Connect-NaController
#$ErrorActionPreference = "SilentlyContinue"

Function IsSnapMirrorDest ($VolName,$Filer)
    #Returns $true or $false to the question
    #Is $VolName a VSM Destination?
    #VSM destination volumes don't handle Get-NaVolAutosize or
    #Get-NaSnapAutodelete well, so this function discovers
    #VSM destination volumes which allows the main function to 
    #avoid querying them for Volume AutoSize or Snapshot AutoDelete
    #which avoids errors

    #I don't need all these variables; some are left for reference, though
    #$SourceFiler = $null
    #$Source = $null
    $DestinationFiler = $null
    #$Destination = $null
    $Pair = $null
    $IsSnapMirrorDest = $null

    #Get the VSM status of the volume
    $Pair = Get-NaSnapmirror $VolName

    #If volume is not in a VSM relationship, the output of
    #the Get-NaSnapmirror function will return a null string
    #This if statement checks to see if the volume is in a VSM
    #relationship and falls into it if it is not
    if($Pair -ne $null)
        #I ended up only needing the $DestinationFiler
        #for this function, but the others are left
        #for reference
        #$SourceFiler = ($Pair.Source.Split(":"))[0]
        #$Source = ($Pair.Source.Split(":"))[1]
        $DestinationFiler = ($Pair.Destination.Split(":"))[0]
        #$Destination = ($Pair.Destination.Split(":"))[1]

        #If this script is run on the destination controller of
        #this volume's VSM relationship, return $true
        if($Filer -eq $DestinationFiler)
            $IsSnapMirrorDest = $true
            return $IsSnapMirrorDest

        #If this script is run on the source controller of
        #this volume's VSM relationship, return $false
        $IsSnapMirrorDest = $false
        return $IsSnapMirrorDest
    #This else condition is used when the volume is not part
    #of a VSM relationship at all
        $IsSnapMirrorDest = $false
        return $IsSnapMirrorDest

$Vol = $null
$ObjVol = $null
$AutoSize = $null
$AutoDelete = $null

#Get controller name for comparison later
$Filer = (Get-NaSystemInfo).SystemName

#Create an empty collection of volumes
$ColVol = @()

#This script counts online and offline volumes for reference
$NumVols = (Get-NaVol).Count
$OnlineVols = 0

foreach($Vol in Get-NaVol)
    #Offline volumes cannot be queried for all conditions, so this
    #script avoids querying them at all to avoid unnecessary work
    #i.e. I'm lazy and didn't want to script for so many conditions
    if($Vol.State -eq "online")
        $OnlineVols = $OnlineVols + 1

        #Look at each option name and decide if it's something
        #I want to query
	    foreach($Option in Get-NaVolOption $Vol.Name)
            #Create a set of properties for custom object assignment later
            $Properties = @{
            #Look at each option name and decide if it's something
            #I want to query. Right now, the options are 
            #1. actual_guarantee
            #2. fractional_reserve
            #3. nosnap
                            "volume" {$ThinProvisioned = "no"}
                            "file" {$ThinProvisioned = "file"}
                            "none" {$ThinProvisioned = "yes"}
                "fractional_reserve" {$FractionalReserve = $Option.Value}
                        if($Option.Value -eq "on")
                            $Snaps = "no"
                            $Snaps = "yes"
            #Create a new custom object for each volume and assign
            #the properties
            $ObjVol = New-Object -TypeName PSObject -Property $Properties
        #keep track of offline volumes for reference
        $OfflineVols = $NumVols - $OnlineVols

        #If a volume is a VSM destination, don't query it 
        if((IsSnapMirrorDest $Vol.Name $Filer) -eq $false)
            #Discover Volume AutoSize settings
            if((Get-NaVolAutosize $Vol).IsEnabled -eq "True")
                $ObjVol.VolAG = "on"
                $ObjVol.VolAG = "off"
            #Discover Snapshot AutoDelete settings
            #GetValue(4) here gets the value of the 5th OptionName
            #(starts counting at 0) in the hash table
            $ObjVol.SnapAD = ((Get-NaSnapshotAutodelete $Vol).GetValue(4)).OptionValue
        #This condition occurs when a volume is a VSM destination. Since
        #Volume AutoSize and Snapshot AutoDelete cannot be queried 
        #without errors, these settings will be called out
        #by "VSM dest," meaning the volume is a VSM destination.
            $ObjVol.VolAG = "VSM dest"
            $ObjVol.SnapAD = "VSM dest"
        #After every pass of a volume, append the custom object to
        #the collection of objects
        $ColVol += $ObjVol    
Write-Host "`n"
Write-Host "--------------------------------"
Write-Host "Controller: " $Filer
Write-Host "Online volumes: " $OnlineVols
Write-Host "Offline volumes: " $OfflineVols
Write-Host "--------------------------------"

$ColVol | Format-Table Name,VolTP,FR,Snaps,VolAG,SnapAD

Options for Managing vSphere Replication Traffic on Cisco UCS

I was recently designing a vSphere Replication and SRM solution for a client and I stated we would use static routes on the ESXi hosts.  When asked why, I was able to 1. discuss why the default gateway on the management network wouldn’t work and 2. present some options as to how we could separate the vSphere Replication traffic in a way that would allow flexibility in throttling its bandwidth usage. 

You won’t see listed here Network I/O Control because this particular client didn’t have Enterprise Plus licensing and therefore wasn’t using a vDS.  In addition, this client was using a fibre channel SAN on top of Cisco UCS with only a single VIC in his blades.  This configuration doesn’t work well with NIOC because it doesn’t take into account FC traffic which is sharing bandwidth with all the Ethernet traffic NIOC *is* managing.

Read the rest of this entry »

DR Options for SQL Server in a vSphere Environment

While SQL Server is not one of my core competencies, I have worked with clients to protect their business critical applications in a VMware environment that utilizes SRM for DR.  These options rely on either Native SQL protection schemes or VMware options like SRM or vSphere Replication.  There are, of course, many 3rd party options, as well, depending on the storage array in use, which I won’t go into here.  While there are usually good, better, and best options, the idea I’d like to get across here is that there are many ways to protect SQL Server.  They can all be used at the same time even.  I’ve had clients that had so many SQL Servers, this is essentially what they did – they had to pick and choose how to protect each based on their relative importance.

SQL Server 2012 AlwaysOn Availability Groups

For the most critical SQL Servers, the image below shows the high-level view of what my clients have used with success.  For server failures at the Primary Data Center, there are multiple SQL Servers.  AAGs can use both an Active-Active model and an Active-Passive model with regard to where the active database resides.  Continuing with the Primary Site, Node 1 can host both an Active and a Passive database.  Node 2 can host an Active and Passive database, as well, working with Node 1 to perform synchronous replication.  Through asynchronous replication, both databases can be replicated to the DR site, where only Passive copies reside.  In the event Site A completely fails, Node 3 can be brought online.

Read the rest of this entry »

Will Write for Fame and Fortune

I had the good fortune this past summer to be presented the opportunity to write a book.  I had been reviewing VMware-related books for some time already when a publishing company reached out with an offer.  I eagerly accepted and began writing in June.  In less than a month, I was done.  Not because I had finished setting pen to paper, but because my topic, vCenter Server Heartbeat, was put out to pasture…then shot.  VMware put the focus of my road to virtualization glory and stardom on its End-of-Life list and stopped selling vCSHB on July 2nd, 2014.  Soon after, my publishing company killed the book, too.

I was disappointed I wasn’t able to finish.  What I did complete, though, I’d like to share, with the hope that maybe someone out there is looking for an author and likes my work. Actually, you don’t even have to like my work to make an offer. I like the idea of writing a book, but articles work well, too, or even training materials. I would most like to write about NetApp – maybe an introduction or a design, installation, and configuration guide.  They have plenty of products that could be written about and besides vendor documentation, there’s not a lot of info in book form.  I especially like the idea of third-party training videos – I know there are several for EMC, but none for NetApp.  I think it’s time to change that. My other interests include VMware and Cisco UCS.

Chapter 1

View this document on Scribd

Chapter 2 (never finished)

View this document on Scribd

NetApp Initiator Group Best Practices for VMFS LUNs

I’m often asked by my clients the best way to configure NetApp igroups when connecting to VMware VMFS LUNs, especially after I deploy a new system for them and I’m training them on their use.  I appreciate the question because it means someone’s actually thinking through why something is configured the way it is rather than just throwing something together.

The Problem

So this is what I see a lot of out in the field.  Single igroups are created with multiple initiators from 5multiple hosts.  This can be a problem, though, as I’ll show you.  Functionally, this configuration will work – each host will be able to see each LUN, all things being equal.  The problem arises when you want to either 1. remove a host from the igroup or 2. stop presenting a LUN to only a subset of hosts.
Read the rest of this entry »

Real World Cisco UCS Adapter Placement

I had the opportunity recently to deploy 18 B420 M3 blades across two sites.  Having only deployed half width blades over the last two years, I had to change my usual Service Profile configuration for ESXi hosts to ensure the vNICs and vHBAs were properly spread across the two VICs installed in each blade.  Each B420 had a VIC 1240 and a VIC1280.  The Service Profile for the blades includes six vNICs and two vHBAs.  The six vNICs were used to take advantage of QoS policies at the UCS-level.  The six vNICs configured included:

  • vNIC FabA-mgmt
  • vNIC FabA-vMotion
  • vNIC FabA-VM-Traffic
  • vNIC FabB-mgmt
  • vNIC FabB-vMotion
  • vNIC FabB-VM-Traffic

Read the rest of this entry »

10 Years, $10, 10 Days at Packt Publishing

Packt Publishing is celebrating 10 years publishing its technical tomes and they’re inviting everyone to celebrate with them.  While this post is coming out at the tail end of the promotion, you still have time to get in on the action.  It’s good until July 5th.

You can buy as many books as you like for $10 each.  Check out their deals here:


Get every new post delivered to your Inbox.

Join 1,283 other followers