NetApp Virtual Storage Console Default Provisioning and Cloning Settings

As a VMware administrator, if you aren’t using Virtual Storage Console (it’s free!) to assist with administering your NetApp storage, you’re missing out on a great tool. It simplifies a lot of tasks through abstraction and a GUI. That being said, I know not everyone has that advantage, especially if you work for an organization where silos are still alive and well.

In order to facilitate best practices when it comes to creating datastores, whether FC/iSCSI LUNs or NFS, I want to publish the settings that VSC uses to create the volumes. As a VMware administrator, you can approach the storage team and ensure the volumes/LUNs/etc. are configured in this manner, or as the storage administrator this is the baseline for VSC configures them.

Remember that these are best practices / recommendations only. They ALWAYS come with the “it depends” caveat…every setup is different, so not all of these may be appropriate for you and your environment.

All of these settings are documented in the VSC Installation and Administration Guide. Additionally, justification and rationale can be found in TR-3749 and TR-4068, the two best practices guides for using vSphere and NetApp together.

Read more

NetApp: Change Virtual Storage Console (VSC) SSL Certificates

Glenn posited an interesting question this morning…how to change the SSL certificate that VSC uses to one that is signed by your CA so that the warning(s) would no longer appear. Turns out it’s significantly more difficult that it probably should be, but it is possible.

First, let me say that NetApp probably hates me doing this and will not support your VSC install in anyway should you modify the key. Also, keep in mind that any updates to VSC may over write the key, thus undoing any of this work. So, proceed at your own risk…

Read more

PowerCLI: Force NetApp Virtual Storage Console (VSC) to use a FQDN

First let me say, I love VCS, it took all of the complexity out of using NetApp storage in a vSphere environment.  I have been tolerating one annoyance for quite some time now, and this morning said annoyance broke VCS at a customer site. What’s wrong with VCS? Well, for some reason it forces you to register the plugin with vCenter using an IP address.  Due to an over-restrictive proxy configuration, which caused only fully qualified domain names(FQDN) worked. Any IP address was redirected to an web page that explained said over-restricted policy, because VCS is mainly a web page the use of an IP address broke everything.  I searched around a little, and found Williams Lams post on removing plug-ins with the MOB. Once I found the pivot point for Plug-ins, I searched the API Reference, and found the ExtensionManager object.   Now that I had the Object in hand, I fired up PowerCLI and in less than 10 min figured out how to manually adjust the URL VSC used. It was so easy that I think I’m going to try and slap together a quick module to manage plug-ins via PowerCLI, but in the meantime if you, like me, have been frustrated by VSCs use of an IP address… try this.

Monitoring for orphaned snapshots left by SMVI

NetApp’s SnapManager for Virtual Infrastructure (SMVI) is a great product, but it’s messy. If it encounters the any error, it seemingly forgets to delete the virtual machine snapshots from the Virtual Infrastructure before dying.

To prevent many orphans (I’ve seen as many as 20 on a single virtual machine) from happening, I created a quick Nagios check that simply alerts when it sees them.

This script is very elementary. It very simply uses a regex to check for any snapshots that match the default SMVI naming convention. For each one it finds, a counter is incremented. If any are found, the script returns an error to Nagios, which causes an alert to be sent.

I’ve set the check to execute once an hour in my environment, as I don’t feel that granularity finer than that is needed…an hour’s worth of change is ok for an SMVI snapshot for me.