Historically NetApp has had a very different vision regarding the value storage array. One of the core values follows along the lines of: In order to be truly valuable, advanced storage features must be made available to the system and in many occasions the application administrative teams. In the absence of this goal, we believe storage is simply storage.
One of the challenges to delivering storage array functionality to the upper layers is to grant only the permissions required for the integration component to function. I covered how to provide this functionality in December with my post: Configuring Role Based Access with the Virtual Storage Console vCenter Plug-in.
In today’s post I’d like to introduce those who only know NetApp from a VMware perspective to SnapDrive for Windows (SDW) and discuss the minimum rights required for SDW to function within a VM.
Actually, I had to work through this issue today with our engineers as Duncan and David for some help accomplishing this for a rather large customer installation.
SnapDrive is a storage management plug-in that allows the server admin to complete storage management tasks. Originally SnapDrive was for physical servers, but today support is also available for VMs to manage physical mode RDMs.
- Provisions new storage on the array – creates, masks, set multipathing, & connects the storage to the node(s)
- Modify storage – access snapshots, grow the LUN and file system
- Clone LUNs – which also masks and connects the clones to the host
- Reclaim the deleted data in thin provisioned LUNs
- Supports FC, iSCSI, FCoE, and NFS
For those of you unfamiliar with SnapDrive we demonstrated some of its capabilities last October as a part of the HP Tech Day 2009 Follow Up. Below are videos where we covered SDW functionality in the webcast. I apologize in advance for the poor quality of the audio.
Windows Server Storage Integration with SnapDrive part 1
Windows Server Storage Integration with SnapDrive part 2
Enabling Controller Functionality in a VM
With servers moving from physical to virtual we had to provide SDW with a means to manage the storage object (or LUN) without breaking the layer of abstraction provided by ESX/ESXi. IN order to provide this functionality SDW is configured to communicate with vCenter. The user account used by the SDW service is required to have access in vCenter.
The current administrative guide for SnapDrive only provides configuring SDW to use a vCenter administrator account for this functionality. Unfortunately this option is insecure for many accounts.
I assure you the admin guide is being revised and the update will post soon.
In the meantime I’d like to provide you with the minimum rights required within vCenter in order to provide a user account for the purposes of SDW. These rights are:
(This is list has been updated – thanks David for the feedback and corrections)
- Datastore.Rename (used for backup mount and VMFS restore)
- Host.Config.AdvancedConfig (used for backup mount and VMFS restore)
- Host.Config.Storage Partition Configuration (used for NFS mount and VMFS mount/restore)
- VirtualMachine.Interact.PowerOff (used for restore)
- VirtualMachine.State.CreateSnapshot (used forbackup)
- VirtualMachine.State.RemoveSnapshot (used for backup and restore)
I hope this information helps those move forward with securely enabling SDW in VMs. I have the draft for the Rapid Cloning Utility RBAC requirements on my laptop and should be posting that soon.
Until then, remember ‘virtualization changes everything’ (including configuring SnapDrive)!