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.
Background
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
SnapDrive is the underlying component that enables our on-disk snapshot backup technologies for Oracle, Exchange, SQL Server, SharePoint Server, and SAP.
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.Browse
- Datastore.Rename (used for backup mount and VMFS restore)
- Gobal.Settings
- 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.Interact.PowerOn
- VirtualMachine.State.CreateSnapshot (used forbackup)
- VirtualMachine.State.RemoveSnapshot (used for backup and restore)
- VirtualMachine.State.RevertToSnapshot
Wrapping Up
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)!
Vaughan,
Thanks for taking the time to post this kind of information. In the VMware world can SnapDrive be used on windows virtual machines to provision additional virtual disks so that they are setup correctly and have the ability to create snapshots? I know it can manage RDM’s but what about the vmdk’s? I hope this question makes sense. Thanks again!
Re: [NetApp – The Virtual Storage Guy] Tony submitted a comment to Creating a Restricted vCenter Role for SnapDrive
Tony,
Thanks for the follow up, great questions!
Yes SnapDrive can create new RDMs, grow them on the fly, create and mount RDM snapshots, etc…
In the near future we will introduce the ability to manage VMDKs with all of the classic SDW functionality. We feel that managing virtual storage objects is the end game to having full integration. We can do much of this now with NFS datastores, and the future only gets better.
Vaughan, Thank you for your quick response. That’s always been the missing piece for me. I love the SnapDrive feature set for physical hosts but in the virtual world it can get a bit messy managing three different methods of provisioning – RDM’s, iSCSI LUNs from within the VM and VMDK’s at the host level. Once this feature comes available I think we’ll really start to see the benefits of running SnapDrive inside the VM. As the technology stands today do you see a lot of adoption from customers using the Microsoft iSCSI initiator at the guest OS level or RDM’s? Some drawbacks that have prevented me from deploying SnapDrive at the guest level are the following:
1.) VM’s generating iSCSI traffic across networks that you may not want. I guess you could always create another vnic but that could get to be cumbersome.
2.) To my knowledge SMVI doesn’t currently support backing up RDM’s or iSCSI software initiated LUNs.
Once you get the management of vmdk’s down I think you are absolutely right that it is the end game to full integration. I’ll eagerly await the next release of SnapDrive! Keep up the great work!
I love the SnapDrive feature set for physical hosts but in the virtual world it can get a bit messy managing three different methods of provisioning.
@Refurbished – SnapDrive enbles SnapManager for Applications to be installed inside of VMs. While it can provision storage it is not the recommended method.
This message was sent by my thumbs… fault them for the brevity and poor spelling
Hi all,
I’m testing a VM running 2003 R2 fully patched. It is file system aligned according to Netapp Best Practice guide(s) and has installed SnapDrive 6.2P1. I used Snapdrive to create a RDM Lun using an igroup of the ESXi clusters Qlogic HBA initiators. The RDMs mapping files are located on a VMFS lun mapped to the ESXi cluster. From Netapp SMVI best practice guide, it states quite clearly that physical mode RDM LUNs are supported as physical mode *should* be excluded from the vmware consistent backup. My experiences of this from testing however, is that the Ontap VSS interferes with the VM backup and the backup job fails.
Any ideas guys?
Ed.
can you tell me what firewalls would need to be opened also