Microsoft Distributed File System (DFS) and DFS-Replication (DFS-R): The Microsoft equivalent is simple to manage from permissions as AD permissions can be applied to DFS virtual folders in a DFS Root. The virtual folders are assigned “targets” that can be spread across nodes. This is where DFS-R comes into the game. For prior migrations, they had utilized host-based tools for copying CIFS or NFS platform storage. In addition, the customer had Microsoft DFS (Distributed File System) sporadically deployed in their environment and wanted to ensure that, where it did exist, all DFS links would be updated to reflect the new target storage.

Answer

Overview

One of the important considerations for deploying NetApp storage to interoperate effectively with the VMware ESX/ESXi guest operating systems in a SAN/NFS environment is to utilize the NetApp recommended guest OS tunings in the virtual machines. This article describes the guest OS tunings utilized and the settings recommended by NetApp to help improve interoperability. The article also describes the purpose of updating guest OS tunings from the previous settings and provides guidance on adopting the updated guest OS tunings.

Why are guest OS tunings required?

The following are some reasons why guest OS tunings are required:

To help improve error handling and interoperability during storage controller failover events.
To improve recovery times following a storage controller failover event.

Deploying Microsoft Dfs With Netapp Storage Systems Pdf

What are the guest OS tunings utilized?

In a typical VMware virtual machine deployment, the guests utilize the local SCSI disks served by the VMware vSphere hypervisor with the backing storage, either using VMware virtual disk (VMDK) or raw device map (RDM) formats. The guest OS tunings recommended are for the SCSI disks inside the virtual machines. In particular, the following is a list of the tunings for the different guest operating systems:

Windows: disk timeout
Linux: disk timeout
Solaris: disk timeout and additional I/O tunings concerning busy/not-ready/reset retries and I/O throttle settings

What are the settings recommended?

Historically, the NetApp tools ESX Host Utilities 5.2.1 and VSC 4.0 set the disk timeout for the Windows, Linux, and Solaris guests to 190 seconds. In addition, they also make adjustments to the I/O tuning settings for the Solaris guest.

With the introduction of more advanced NetApp storage controller clustered technologies, in addition to aligning to newer versions of VMware vSphere best practices and to correct the vendor ID (VID) and product ID (PID) information on Solaris I/O tuning specifications, NetApp has decided to update the guest OS tunings. The following table summarizes the historical guest OS tunings and the updated guest OS tunings.

Guest OS Type	Historical Guest OS Tuning for SAN	Updated Guest OS Tuning for SAN
Windows	disk timeout = 190	disk timeout = 60
Linux	disk timeout = 190	disk timeout = 60
Solaris	disk timeout = 190 busy retry = 300 not ready retry = 300 reset retry = 30 max. throttle = 32 min. throttle = 8	disk timeout = 60 busy retry = 300 not ready retry = 300 reset retry = 30 max. throttle = 32 min. throttle = 8 corrected VID/PID specification

What are the NetApp guidelines for deployment?

Use the following guidelines to determine if you should update the guest OS tunings:

There is no need to update the guest OS tunings for your VMware NFS deployment, the VMware Tools default timeout setting is sufficient. This KB addresses the guest OS tuning updates for a VMware SAN deployment.
There is no need to update the Windows and Linux guest OS tunings in existing solutions that are working well with the historical guest OS tuning settings.
For the Solaris guest OS, adopt the corrected VID/PID information provided below to help improve error handling and interoperability during storage controller failover events.
When deploying new solutions with ESXi 5 and later, or Data ONTAP 8.1 and later, adopt the updated guest OS tunings to help improve the recovery times following a storage controller failover event.
When upgrading the ESX/ESXi hosts or NetApp storage controller software to a recent release, utilize the opportunity to also deploy the updated guest OS tunings.
If you are utilizing software iSCSI initiator from the guest OS, please follow respective NetApp documentations on the native OS interoperability requirements for supported configurations, multipathing configurations, and any additional required tunings in Host Utilities.

How to implement the updated guest OS tunings

You can manually configure the virtual machines with the recommended guest OS tunings or utilize the scripts bundled within VSC to implement the tunings. Reboot the guest after the tuning update for the settings to take effect.

Manual Configuration

Warning: Using Registry Editor incorrectly might cause serious problems that require reinstalling your operating system. Make a backup copy of the registry before making any changes to the Windows registry.

Windows: Set Windows disk timeout to 60 seconds by using the TimeOutValue registry key located below:
HKEY_LOCAL_MACHINESystemCurrentControlSetServicesDiskTimeOutValue

Deploying Microsoft Dfs With Netapp Storage Systems Free

Linux: Set Linux disk timeout to 60 seconds can be achieved by creating an udev rule with the following entry.
DRIVERS'sd', SYSFS '0|7|14', RUN+='/bin/sh -c 'echo 60 > /sys$$DEVPATH/device/timeout'
- Note that the Linux guest OS tuning script bundled with NetApp VSC adds a script to udev rules with an entry similar to the above. (Different Linux distribution might have a different location for the installed udev rule.)
- In addition, the VMware Tools in the Linux guest OS provide an udev rule to set the disk timeout to 180 seconds automatically for VMware virtual disks. You can 'grep' for the 'VMware' vendor ID in the udev rules directory to find out which script was installed by VMware and modify it accordingly.
- Verify again after a VMware Tools update to ensure the disk timeouts is at the desired value.
RHEL 7.x:
ACTION'add', SUBSYSTEMS'scsi', ATTRS{VENDOR}'VMware ', RUN+='/bin/sh -c 'echo 60 >/sys$$DEVPATH/timeout'
ACTION'add', SUBSYSTEMS'scsi', ATTRS{VENDOR}'NETAPP ', ATTRS{MODEL}'LUN ', RUN+='/bin/sh -c 'echo 60 >/sys$$DEVPATH/timeout'
ACTION'add', SUBSYSTEMS'scsi', ATTRS{VENDOR}'NETAPP ', ATTRS{MODEL}'LUN C-Mode ', RUN+='/bin/sh -c 'echo 60 >/sys$$DEVPATH/timeout'
Solaris: Set Solaris disk timeout to 60 seconds can be done by having the following setting in the /etc/system file.
set sd:sd_io_time=0x3c

The additional Solaris I/O tuning parameters can be added to /kernel/drv/sd.conf by specifying the following setting entries.

Deploying microsoft dfs with netapp storage systems online

Solaris 10.0 GA thru Solaris 10u6:
sd-config-list='NETAPP LUN','netapp-sd-config', 'VMware Virtual','netapp-sd-config'; netapp-sd-config=1,0x9c01,32,0,0,0,0,0,0,0,0,0,300,300,30,0,0,8,0,0;

Note: There are exactly two spaces between the vendor