VDR - Adding NFS Network Share

[phykell]

Hi,

I've set up an NFS share on a Dell NAS running Windows Storage Server 2008 and Active Directory Lightweight Directory Services (AD LDS) to provide user name mapping from UNIX to Windows.

I can add the NFS share as a datastore to my ESXi host with no issues; but for some reason, I can't add the same NFS share to a VDR appliance running on an ESXi host even if that host is the one running the VDR!

When adding an NFS datastore to a host, the dialog asks me for following:

• Server: "111.222.333.444"
• Folder: "MyNFSShare"
• Datastore Name: "MyNFSDatastore"

When adding a destination to the VDR, the dialog asks me for the following:

• URL: "\\111.222.333.444\MyNFSShare"
• User Name: "<NFS Share Username>"
• Password: "<NFS Share Password>"

I've also tried entering the vCenter Administrator user credentials but it makes no difference and the event log on the NAS is reporting a successful security event "Audit Success" for the user logon anyway.

Can anyone shed any light on this?

[phykell]

I gave up trying to connect to the NFS share from the VDR and instead decided to add a virtual disk on the datastore accessible to the host running the VDR appliance. I was then able to see the new virtual disk in the VDR after rebooting the appliance at which point I formatted the drive and it mounted just fine.

The remaining issue I have is that the performance is terrible - the virtual disk is only sized at 20GB for testing purposes and it took ages to format. When I then tried to run a backup of a small VM, it took ages to even get to the point where it had "opened" the deduplication store - consequently I had to cancel the backup job as there's definitely something wrong:

• ESXi is on 1.0.0.1
• NAS is on 2.0.0.1
• VDR is on 2.0.0.2

This configuration looks fine to me...

I never had any such problems using my old Windows Storage Server 2003 NAS!

[Marcj1 · Accepted solution]

VDR does not accept NFS as destinations, but it does accept CIFS.  So, instead of trying to add an NFS target add a windows share using actual windows (or domain) credentials.

I too seem to get better performance from a Linux NFS instance than a Windows, I think because the Windows implementation is not spec compliant.  If i watch the console while doing a format of a vmdk hosted on a Windows based NFS target the connection appears to constantly go in and out.  I now have it running on a Windows 2008 R2 server and it runs well enough for my purposes, which hosting the VDR vmdk's so i can write them off to tape.

[DSTAVERT]

Just create a new VMDK disk on the NFS datastore. Works well and far better than a CIFS share for vDR.

[phykell]

Agreed - I think that I can't connect to the NFS share using the Windows credentials anyway but I'm very surprised as it seems that the VDR is therefore limited to the following types of destination:

• CIFS (Windows share),
  
• VMDK on a datastore which can specify fibre, iSCSI or NFS as a device.
  

Is that correct?

I've changed the subnet of the host containing the VDR to the same as the NAS. I've added a virtual disk to the VDR and I'm watching it do a backup now. It seems much faster now. It eventually completed the inital backup of a 25 GB VM in less than 30 minutes and a subsequent incremental then took less than a minute.

[Marcj1]

You are correct, CIFS (windows share) or VMDK on any datastore the host can see.   You can use windows credentials if the NFS target is also set as a windows share, by using the windows share path.  Only the host will see the NFS path.

Yeah, i have always had problems formating a vmdk hosted on a Windows based NFS target, but once it is formatted it seems to work well enough.  i have even gone as far as creating and formating a vmdk on SAN storage, then migrating it to NFS.

[DSTAVERT]

You are correct. CIFS is not a recommended destination in spite of the fact that it is available.

[phykell]

I think this is where I've been going wrong. I've set up a NAS previously on another system and assumed it was using NFS - I'd set up UNIX name mapping, etc. via that NAS' user interface. Having done a quick test on that other NAS I can see that the folders I'd assumed were being shared using NFS are actually using CIFS. The dead giveaway is that I can see the individual files on my backup destination from Windows, rather than just seeing a single large file representing the VDK.

The formatting of the 20 GB disk seemed to take quite a while but I don't believe I got the option to use thin provisioning. If I wish to have a maximum destination size of (say) 500GB, how long is that going to take to format via the VDR? It's not as if the VDR provides any useful progress reporting on the formatting process either so I just have to wait for it to finish - not ideal really.

[phykell]

When you say that a VMDK disk on NFS works "far better" than CIFS, what do you mean exactly? Is it more reliable or is it just improved performance I can expect?

[Marcj1]

Thin provisioning will not work when the NFS is hosted on Windows, again because of the lack of compliance.  So thick is your only option.  I have been able to get my 550 GB vmdks hosted on Windows NFS to format within 4 hours.  The following link provides some best practices for optimizing NFS on the vmware side:

http://www.vmware.com/files/pdf/VMware_NFS_BestPractices_WP_EN.pdf

And this on the Windows side for Server 2003:

http://technet.microsoft.com/en-us/library/bb463205.aspx

You can format the vmdk manually by sshing into the appliance to see the progresss.  To is a shame the progress is not available from the GUI.

As for CIFS vs NFS, you can generally expect both better reliability, because NFS can be much more forgiving with network interuptions, etc., and performance, because NFS has less overhead than Windows CIFS.

[phykell]

Thanks - everything's working great now and that NFS document is a good find!

My 512GB VMDK formatted pretty quickly - no more than 30 minutes and a backup I just did ran at 1.6 GB per minute in the middle of the day.

Points awarded to all