If I understand the the situation it is not possible to present an RDM that does what you are trying to do given what you already have - you have to create something different.
An RDM is a LUN presented from storage to the VM hosts, then mapped directly to a VM guest as a single entity, as opposed to presenting the LUN just to the VM hosts and letting the hosts carve out pieces of the LUN as virtual disks. Both RDMs and traditional VMDKs are just different chunks of disk that the guest controls directly.
What you indicate you have is a volume already shared out via CIFS. There isn't any way to convert or present that as a LUN directly mounted as an RDM into a VM so it can be re-shared. That's pretty much the point of virtual disks, whether traditional or RDM mounted to the guest. The guest OS controls the contents of the the virtual disk. With a CIFS share another entity is already controlling the content of the "disk" space.
Using the structure you have doesn't seem to make sense for how you want it to be presented. If you have to maintain the CIFS shares as is and represent as if they are on another server as well, perhaps symbolic links or DFS or similar might be in order. If all the data currently shared via CIFS is to be reshared, recreating that CIFS share based on your VM is straight forward - just involves copying the information and representing. However if the existing CIFS share has additional data that needs to be maintained, you'll have to get creative.
Thanks for your response. I am not sure I understand it fully but basically I am trying to do a simple thing - have NetApp present data to a Windows File Server (let's call it FSERVER) so that that data can then be shared as normal file share and accessed by workstations / end users (lets call them WSTATIONS). So in the end on any of WSTATIONS data should be accessible like: \\FSERVER\DATA
So in another way I have
NETAPP > FSERVER (here I share folder called DATA with all windows users) > WSTATIONS should see DATA share
What I don't want to do is to share data directly from NETAPP to WSTATIONS - we need more control that Windows File Server allows.
Sorry not sure how better to explain this. I am sure thousands of companies do this all the time, there must be some very simple and straightforward solution.
Ok so that far I'm following you. So addressing this on two fronts:
1. What capabilities do you need from a true Windows file server that you can't get from NetApp storage presenting the share? I'm curious only because until you get really down into the weeds there is little that you can't do from both (but there are a few things depending on your version of OnTap).
2. The meatier discussion. As I mentioned before, if you want to share data from FSERVER, you have to present something that looks like a disk to the VM. That means creating either a VMDK on an ESX datastore (LUN or NFS attached to the ESX host) or creating a LUN on storage that is presented as an Raw Device Map (RDM) disk through ESX. For all intents the RDM mechanism is the same affect as the standard VMDK, but it also takes a minimum of two LUNs to create - one to hold the VM and the RDM link file, and one to be "the disk".
The upshot of #2 is this - if you already have a share presented from the NetApp, there is no way to directly convert the share or to present that to ESX in a way that will allow an FSERVER VM to share it again. Unless you need something really special from OnTap (some sort of direct snapshot control or cloning or something you can't easily do from ESX directly or from ESX with VSC for instance) there is no advantage to using an RDM - create a new VMDK, attach it to the FSERVER VM, and copy the data from where it is to the FSERVER VM. Even if you did go the RDM route, you are still making a new copy of the NetApp shared data.
Hope this helps
Lead Storage Engineer, Consilio LLC
NCIE SAN, Data Protection
Kudos and accepted solutions are always appreciated