If you are using Nimble Storage with Windows servers, chances are you have the Nimble Windows Toolkit installed. It’s an integral part of connecting Nimble volumes to your Windows server including components such as our MPIO DSM and Nimble Connection Manager.


Did you know that installing NWT also provides you with some useful PowerShell tools? Yep, it’s true; and there is a new cmdlet included which can be particularly helpful when connecting to clones of existing volumes. Using this cmdlet greatly simplifies the process and makes it so that the connection can be entirely automated. In this blog post, we’ll take a look at an example in which we create a clone from a VSS synchronized snapshot of a SQL database.


First, let’s inspect those PowerShell cmdlets.  In order to use them, you need to import the Nimble PowerShell module, which NWT installs at

C:\Program Files\Nimble Storage\bin\Nimble.Powershell.dll




As you can see, there are four cmdlets included in this module. For this workflow, we’re going to focus on Get-NimVolume and Set-NimVolume.


To understand just how useful these cmdlets can be, it’s worthwhile to take a look at what the process would look like without them.


Let’s assume we’ve created and connected to our clone volume. That’s great, but we can’t quite use it yet. Why not you ask? Well, let’s take a closer look at it.  What does the Windows Disk Management tool have to say about it?

disk offline.png


OK, it’s offline. No big deal, we’ll just right-click on the disk and ask windows to bring it online:


disk online no driveletter.png


Is that all we need to do? Well, unfortunately no it isn’t. Let’s peel back the onion a bit more and take a look at the attributes which are set on the disk. For these, we’ll use the venerable diskpart tool.




OK, we have some work to do. Our volume is read-only, hidden, marked as a snapshot, and doesn’t have a drive letter. We’ll have to modify these attributes with diskpart before we can use our newly created clone.


Enter PowerShell.


Get-NimVolume will help us discover our Nimble volumes, and Set-NimVolume will let us programmatically bring the volume online, set the correct attributes, and give it a drive letter. Let’s find our clone volume with Get-NimVolume:




OK cool, we found our clone volume. How do we go about bringing it online and setting those attributes? Here’s where we would use Set-NimVolume. Let’s see what parameters this cmdlet takes:




As you can see here, we can specify the volume we want to modify be feeding Set-NimVolume a windows disk ID, or a Nimble volume serial number, which we can get from Get-NimVolume. To make things even easier, we can simply pipe the output from Get-NimVolume directly into Set-NimVolume.


Since we’ve already found our clone volume with Get-NimVolume, let’s just send it over to Set-NimVolume and set those attributes:




Boom. Done! In one fell swoop, we’ve brought the volume online, set all the appropriate attributes, and requested a drive letter. We can verify all of this using Disk Management and diskpart if we’d like to:




disk online.png


Now our volume is ready for use.  We can mount up the database contained within it for test and development, data recovery, or whatever purpose we had in mind. It doesn’t take a big stretch of the imagination to figure out workflows in which this can be extremely useful. 


For example, what if we wanted an automated way to refresh a test/dev database on a daily basis from a nightly VSS synchronized snapshot of a source database?  That’s not something we want to do manually, but with these cmdlets we can fully automate it as part of a larger PowerShell script.


Or perhaps we are replicating our Nimble volumes to a downstream array and we want to automate the connection process after promoting our downstream volumes?


Or perhaps we’re using Site Recovery Manager from VMware and want to fully automate the workflow for our VMs which are using in-guest iSCSI connections and taking advantage of Nimble’s application specific VSS synchronization?