Subscribe

Presenting NetApp share to VMware that allows Windows file server to further share it

[ Edited ]

My manager created a CIFS share from NetApp that I'm supposed to use in a Windows 2012 VM. I am trying to create shared folders from that CIFS data but Windows doesn't allow re-sharing network folders - CIFS is already visible as something like \\name\sharename on the server and it is not seen as a drive. Any ideas how to present NetApp as a drive instead?

Re: Presenting NetApp share to VMware that allows Windows file server to further share it

[ Edited ]

if i understood your query correctly , you want to do something like this

 

cmd

c:\>net use s: \\tower\movies

 

this should mount the share \\tower\movies to S drive in the system

 

reference :

link1

 

link2

 

thanks

SR

 

 

 

Re: Presenting NetApp share to VMware that allows Windows file server to further share it

Windows will not allow you to re-share a CIFS mount from another system.  It only allows you to create shares on local disks or block devices. Try one of these options instead:

  1. Create the required shares on the NetApp controller, since it is already providing those services.
  2. Add a VMDK or RDM to the windows VM and use that to store your shares
  3. present an iSCSI lun to the windows VM, and use that to store your shares

 

If this post resolved your issue, help others by selecting ACCEPT AS SOLUTION or adding a KUDO.

Re: Presenting NetApp share to VMware that allows Windows file server to further share it

2. RDM is what I understand we need - this would allow to see the data as if it was a physical HDD plugged in to the VM. How can this be done? Could you provide some steps or point me in the right direction?

 

Other options you mentioned:

1. If you mean to use the shares directly from NetApp without Windows Server in between - this has some limits (does not work very well on a Mac) and doesn't allow as much control as with Windows shares

2. VMDK - this is an option but loses some benefits of using NetApp apparently

3. iSCSI we already use for Exchange and for reasons I didn't quite grasp we don't want to use it in this scenario