Install Snap drive with all necessary Fixes. (Windows Fixes, Network Card Driver, LSI Logic Driver)
On the Netapp Filer make the Volumes.
Make as well the LUNs (it has to be Windows) on the Netapp Filer and map it (remeber the LUN ID).
Change back to the VC and add the LUNs as RAW Disk Mapping (Take the same LUN IDs). This has to be done within the properties of the vm (Add disk wizard)
Start up the Machine. Go to the Computer Management and then go to Disk Management. If you see the Disk initialize them and format them. If not make a rescan. (Menu Action)
Open Snap Drive
Now you should see the LUNs, manageable by snapdrive.

Make sure to create the RDM LUN as type Windows - the filer owns the filesystem on the RDM. Unless things have changed since 6.0, if you want to use snapdrive within a VM and utilize your FC HBA connections you have to follow the steps I outlined. Maybe 6.2 changes that - I don't know I'm afraid. If you plan on using iSCSI as your protocol then yes, you create the LUN with snapdrive.

Thanks!  We now have this working with Exchange running on ESX VMs in a CCR configuration.  There's a couple of oddities, however they are not show-stoppers.  One item of note: Occassionally when the VM reboots, SnapDrive loses visibility of the RDM LUNs, however the guest OS still sees/can access them. So far the work-around is simply to stop/restart the SD6.2 services (both of them).  I suspect it's a timing issue as SD has to authenticate with the filer and the vCenter Server (which in turn needs to talk to the right ESX host) or at least with the ESX host directly (depending on how it's setup).  Any thoughts on how to fix the 'disappearing LUNS from SnapDrive on a VM' problem (besides our stop/restart SD services work-around as above)?

Dear Satish,

Thanks! We were using SD 6.2 from mid-OCT, so it may have been an earlier build that exhibited this bug even when doing soft (clean OS shutdown/restarts) reboots.  We did not try a hard power-off reboot.