Skip to main content
NetApp Knowledge Base

What are the guest OS tunings needed for a VMware vSphere deployment?

Views:
4,553
Visibility:
Public
Votes:
7
Category:
virtual-storage-console-for-vmware-vsphere
Specialty:
virt
Last Updated:

 

Applies to

  • SAN
  • NFS
  • FlexPod 

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. 
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_MACHINE\System\CurrentControlSet\Services\Disk\TimeOutValue 
  • 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. 

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 ID NETAPP and product ID LUN as well as between VMware and Virtual in the sd-config-list above. 

Solaris 10u7 and later and Solaris 11:
sd-config-list= "NETAPP  LUN","physical-block-size:4096,retries-busy:300,retries-timeout:16,retries-notready:300,retries-reset:30,throttle-max:32,throttle-min:8",
"VMware  Virtual","physical-block-size:4096,retries-busy:300,retries-timeout:16,retries-notready:300,retries-reset:30,throttle-max:32,throttle-min:8";

Utilizing scripts provided by VSC

NetApp Virtual Storage Console (VSC) provides the scripts to help reduce the efforts involved in manually updating the guest OS tunings. For more information on whether the scripts are used and to review the settings since earlier versions of VSC sets the disk timeout to 190 seconds, see the VSC documentation in the NetApp Support site.

The contents of KB 2010823 have been moved into this KB (formerly KB 41511).

Additional Information

Add your text here.

 

Sign in to view the entire content of this KB article.

New to NetApp?

Learn more about our award-winning Support

NetApp provides no representations or warranties regarding the accuracy or reliability or serviceability of any information or recommendations provided in this publication or with respect to any results that may be obtained by the use of the information or observance of any recommendations provided herein. The information in this document is distributed AS IS and the use of this information or the implementation of any recommendations or techniques herein is a customer's responsibility and depends on the customer's ability to evaluate and integrate them into the customer's operational environment. This document and the information contained herein may be used solely in connection with the NetApp products discussed in this document.