Add Host/Host Cluster to Existing Datastore Cluster

At that time while you are creating the datastore cluster you have this option to select the host or cluster

But Suppose only one of the host/host cluster is selected by you here then how you can add the another host/host cluster in the datastore cluster (and even you cannot click next without selecting anything at this above given screen.)This is what the question (?) raised many time so there is no need to add it explicitly in your datastore cluster. If the same LUNs are visible to those hosts also from which the datastore is created by you and that is the part of the datastore cluster then that datastore cluster will be visible to them also.

Mem.MinFreePct sliding scale function

Check this Vmware Blog Article:-
http://blogs.vmware.com/vsphere/2012/05/memminfreepct-sliding-scale-function.html

Add vMA5 to Domain

1.) Log in to vMA console as vi-admin.

2.) Add vMA to the Domain.

3.) Enter Administrator Account Password

4.)  Restart vMA
      sudo init 6

5.) Login to vMA console as vi-admin and confirm the domain join was successful

6.) Connect with vMA Console and Use the AD user Credential to Login

Using vscsiStats for Storage Performance Analysis

Go to this link:-
http://communities.vmware.com/docs/DOC-10095

Controlling LUN queue depth throttling in VMware ESX/ESXi

Symptoms

• If the ESX host detects a queue full condition, it may abort the SCSI commands
• Queue Full may show up as QFULL or Task Set Full state
• If QFULL conditions exist, the ESX VMkernel log may contain entries similar to:
• In ESX 3.x
  
  status = 40/0 0x## 0x## 0x##
  
• In ESX/ESXi 4.0 and later:
  
• H:0x0 D:0x28 P:0x0 Valid sense data: 0x## 0x## 0x##
• H:0x0 D:0x08 P:0x0 Valid sense data: 0x## 0x## 0x##

The hexadecimal 28 or decimal 40 in the error is the SCSI status code for the queue full state. The value 0x08 in the above error is the SCSI Status code indicating a device busy state.

• In ESX/ESXi 4.0 and later, you also see a device busy error

Resolution

VMware ESX 3.5 Update 4 introduces an adaptive queue depth algorithm that adjusts the LUN queue depth in the VMkernel I/O stack. This algorithm is activated when the storage array indicates I/O congestion by returning a BUSY or QUEUE FULL status. These status codes may indicate congestion at the LUN level or at the port (or ports) on the array. When congestion is detected, VMkernel throttles the LUN queue depth. The VMkernel attempts to gradually restore the queue depth when congestion conditions subside.

This algorithm can be activated by changing the values of the QFullSampleSize and QFullThreshold parameters. When the number of QUEUE FULL or BUSY conditions reaches the QFullSampleSize value, the LUN queue depth reduces to half of the original value. When the number of good status conditions received reaches the QFullThreshold value, the LUN queue depth increases one at a time.

Note: Careful consideration is needed if multiple hosts access the same LUN or array ports. For the adaptive queue depth algorithm to be effective, all hosts accessing the LUN/port must have some form of adaptive queue depth algorithm. If some hosts run the adaptive queue depth algorithm while other hosts do not, the hosts that are not running the algorithm may consume the resources/slots on the array that are freed up by the adaptive hosts. This causes the hosts running the algorithm to exhibit lower disk I/O throughput. This may also increase the I/O congestion that initially triggered the adaptive algorithm.

If hosts running operating systems other than ESX/ESXi are connected to array ports that are being accessed by ESX/ESXi hosts, and the ESX/ESXi hosts are configured to use the adaptive algorithm, either make sure the operating systems use an adaptive queue depth algorithm or isolate those hosts on different ports on the storage array.

VMware ESX versions 3.5-5.0

In ESX/ESXi versions 3.5-5.0,  QFullSampleSize and QFullThreshold are system-wide configuration parameters. Even if the system has different vendor storage arrays connected, all the arrays experience the throttling effect if one LUN/port from any array returns the QUEUE FULL or BUSY errors.

To enable the algorithm:

1. Use the vSphere Client or vSphere Web Client to navigate to the Configuration tab of the VMware ESX host you want to modify.
   
2. Click Advanced Settings under the Software section.
   
3. Click Disk in the left side pane.
   
4. Set QFullSampleSize to a value greater than zero. The usable range is 0 to 64.
   
   • For 3PAR, NetApp and IBM XIV storage arrays, set the QFullSampleSize value to 32.
   • For other storage arrays, contact your storage vendor.
     
5. Set QFullThreshold to a value lesser than or equal to QFullSampleSize. The usable range is 1 to 16.
   
   • For 3PAR storage arrays, set the QFullThreshold value to 4.
   • ForNetApp and IBM XIV storage arrays, set the QFullThreshold value to 8.
   • For other storage arrays, contact your storage vendor.

The settings take effect immediately. You do not need to reboot the ESX/ESXi host.

VMware ESXi 5.1

In ESXi releases earlier than ESXi 5.1,  QFullSampleSize and QFullThreshold are set globally, that is, on all devices seen by the ESXi host. In VMware ESXi 5.1, these parameter are not set globally because different vendors have different optimal values for their arrays. You set QFullSampleSize and QFullThreshold on a per-device level.

Run the following ESXCLI command:. 
esxcli storage core device set --device  device_name --queue-full-threshold  
Q --queue-full-sample-size S 

Settings are persistent across reboots. 
You can retrieve the values for a device by using the corresponding list command. 

esxcli storage core device list

The command supports an optional --device parameter. 

esxcli storage core device list --device device
The recommended values are the same as in earlier releases.
QFullSampleSize:

• For 3PAR, NetApp and IBM XIV storage arrays, set the QFullSampleSize value to 32.
• For other storage arrays, contact your storage vendor.

QFullThreshold:

• For 3PAR storage arrays, set the QFullThreshold value to 4.
• ForNetApp and IBM XIV storage arrays, set the QFullThreshold value to 8.
• For other storage arrays, please contact your storage vendor.

Source:-

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1008113

Configuring CA signed certificates for ESXi 5.x hosts

Purpose

This article guides you through the configuration of Certificate Authority (CA) certificates for a ESXi 5.x host. The instructions provided help you eliminate common causes for problems during certificate implementation, including configuration steps and details, and avoid misconfiguration in implementation of custom certificates in your environment.

Resolution

Note: This article is part of several resolution paths. Before following the steps in this article, see Implementing CA signed SSL certificates with vSphere 5.0 (2015383) or Implementing CA signed SSL certificates with vSphere 5.1 (2034833).

 

Creating CA assigned certificates for an ESXi 5.x host is a complex task. In many organizations it is required to maintain proper security for regulatory requirements. Each server must be unique to the component as it ties to the fully qualified domain name of the server. As such you cannot just take a single certificate and apply it to all hosts. Wildcard certificates are currently not supported, but even if they were, it is much more secure to have a proper certificate for each host. There are several different work flows required for a successful implementation:

• Creating the certificate request
• Getting the certificate
• Installation and configuration of the certificate on the ESXi host

These steps must be followed to ensure successful implementation of a custom certificate for an ESXi 5.x host. Before attempting these steps ensure that:

• You have a vSphere 5.0 or vSphere 5.1 environment
• You have followed the steps in the configuring SSL article
• You have an SSH client (such as Putty) installed
• You have a SFTP/SCP client (such as WinSCP) installed

Generating a certificate request

To generate a certificate request for an ESXi 5.x host:

1. Launch a command prompt and navigate into the OpenSSL directory as previously configured in the Configuring OpenSSL article. By default this is C:\OpenSSL-Win32\bin.
2. Execute the command:
   
   openssl req -new -nodes -out rui.csr -keyout rui.key -config openssl.cfg
   Note: There are no prompts because all information was provided in the openssl.cfg file as configured in the previous article.
   
   This will create the certificate request rui.csr.

When rui.csr is created, proceed to Getting the certificate.

Getting the certificate

After the certificate request is created, the certificate must be given to the certificate authority for generation of the actual certificate. The authority will present a certificate back, as well as a copy of their root certificate, if necessary. For the certificate chain to be trusted, the root certificate must be installed on the server.

 

Follow the appropriate section below for the steps for the certificate authority in question.

For Commercial CAs:

1. Take the certificate request (rui.csr, as generated above) and send it to the authority in question.
2. The authority will send back the generated certificate.
3. Install the root certificate onto the vCenter server before proceeding to the Installation of the certificate section of this document.

For Microsoft CAs:

1. Log in to the Microsoft CA certificate authority web interface. By default, it is http://<servername>/CertSrv/
2. Click Request a certificate.
3. Click advanced certificate request.
4. Click Submit a certificate request by using a base-64-encoded CMC or PKCS #10 file, or submit a renewal request by using a base-64-encoded PKCS #7 file.
5. Open the certificate request in a plain text editor.
6. Copy from -----BEGIN CERTIFICATE REQUEST----- to -----END CERTIFICATE REQUEST----- into the Saved Request box.
7. Click Web Server when selecting the Certificate Template.
8. Click Submit to submit the request.
9. Click Base 64 encoded on the Certificate issued screen.
10. Click Download Certificate.
11. Save the certificate on the desktop of the server as rui.crt. When complete, proceed to Installing and configuring the certificate on the ESXi host to complete the configuration of the custom certificate.

For OpenSSL Self-Signed Certificates:

1. Create the certificate by running the command:
   
   openssl req -x509 -sha256 -newkey rsa:2048 -keyout rui.key -config openssl.cfg -out rui.crt -days 3650
   This command outputs the certificate as needed to proceed to the installation and configuration section of this article.

Installing and configuring the certificate on the ESXi host

After the certificate is created, complete the installation and configuration of the certificate on the ESXi 5.x host:

1. Log in to vCenter Server
2. Put the host into Maintenance Mode.
3. Navigate to the console of the server to enable SSH on the ESXi 5.x host.
4. Press F2 to log in to the Direct Console User Interface (DUCI).
5. Click Troubleshooting options > Enable SSH.
6. Log in to the host and then navigate to /etc/vmware/ssl.
7. Copy the files to a backup location, such as a VMFS volume.
8. Log in to the host with WinSCP and navigate to the /etc/vmware/ssl directory.
9. Delete the existing rui.crt and rui.key from the directory.
10. Copy the newly created rui.crt and rui.key to the directory using Text Mode or ASCII mode to avoid the issue of special characters ( ^M) appearing in the certificate file.
11. Type less rui.crt to validate that there are no extra characters.
    
    Note: There should not be any erroneous ^M characters at the end of each line.
    
12. Switch back to the DCUI of the host and select Troubleshooting Options > Restart Management Agents.
13. When prompted press F11 to restart the agents. Wait until they are restarted.
14. Press ESC several times until you logout of the DCUI.
15. Exit the host from Maintenance Mode. 

When complete, the host is be made available and successfully rejoins the HA cluster. 

 

If you are not running vCenter Server 5.0 U1 or later, the configuration of VMware HA will fail with an error. This is due to a known issue where the new SSL thumbprint is not updated in the vCenter database for VMware HA. For more information on this error, see After upgrading to vSphere5, you see the HA error: vSphere HA Cannot be configured on this host because its SSL thumbprint has not been verified (2006210). The easiest way to resolve this issue is to follow the Alternative Workaroundsection of the KB article, which uses HostReconnect.pl (attached to the article) to reconnect the servers to vCenter Server updating the expected SSL thumbprint in the vCenter Servr database. When complete, run a reconfigure of vSphere HA for the configuration to proceed successfully.

 

The configuration of the custom certificate is now complete. Repeat these steps for each host which needs to have a custom certificate.

Additional Information

 Implementing CA signed SSL certificates with vSphere 5.0 (2015383)

Source:-

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2015499

Masking a LUN from ESX and ESXi using the MASK_PATH plug-in

Details

This article provides steps to mask a LUN from ESX 4/ESXi 4.x and ESXi 5.0 using the MASK_PATH plug-in.

VMware recommends this procedure when unpresenting a LUN to avoid the All-Paths-Down (APD) condition. For more information, see Virtual machines stop responding when any LUN on the host is in an all-paths-down (APD) condition (1016626).

The APD issue is resolved in ESX/ESXi 4.1 Update 1, ESX/ESXi 4.0 Update 3, and ESXi 5.0.

Note: If you are unpresenting a LUN containing a datastore, see:

• Unpresenting a LUN in ESXi 5.x (2004605)
• Removing a LUN containing a datastore from VMware ESXi/ESX 4.x (1029786)

Solution

Caution: This procedure only applies to LUNs that are being managed by the VMwre NMP multipathing service. If you are using 3rd party multipathing plugin such as Powerpath/VE then LUNs must be excluded from the 3rd party multipathing software and put under NMP control before they can be masked again properly.

To mask a LUN from ESX/ESXi 4.x and ESXi 5.0 using the MASK_PATH plug-in:

Note: Any differences in the commands between ESX/ESX 4.x and ESXi 5.0 will be noted with the version of ESX/ESXi before the command.

1. Log into a console or SSH session on your host. For more information, see Using Tech Support Mode in ESXi 4.1 and ESXi 5.0 (1017910).
2. Look at the Multipath plug-ins currently installed on your ESX with the command:
   
   # esxcfg-mpath -G
   
   The output indicates that there are, at a minimum, 2 plug-ins: The VMware Native Multipath plug-in (NMP) and the MASK_PATH plug-in (ESXi 5.0 will only show the NMP plugin by default), which is used for masking LUNs. There may be other plug-ins if third-party software (such as EMC PowerPath) is installed. For example:
   
   # esxcfg-mpath -G
   MASK_PATH
   NMP
   
3. List all the claimrules currently on the ESX with the command:
   
   ESXi 5.0: # esxcli storage core claimrule list
   
   ESX/ESXi 4.x: # esxcli corestorage claimrule list
   
   There are two MASK_PATH entries: one of class runtime and the other of class file.
   
   The runtime is the rules currently running in the PSA. The file is a reference to the rules defined in/etc/vmware/esx.conf. These are identical, but they could be different if you are in the process of modifying the/etc/vmware/esx.conf.
   
   Note: There is already a rule of vendor=DELL model=Universal Xport. This means that pseudo or management LUNs with these attributes are masked from the ESX.
   
   The output from the command is similar to:
   
   Rule Class Type Plugin Matches
   0 runtime transport NMP transport=usb
   1 runtime transport NMP transport=sata
   2 runtime transport NMP transport=ide
   3 runtime transport NMP transport=block
   4 runtime transport NMP transport=unknown
   101 runtime vendor MASK_PATH vendor=DELL model=Universal Xport
   101 file vendor MASK_PATH vendor=DELL model=Universal Xport
   65535 runtime vendor NMP vendor=* model=*
   
4. Add a rule to hide the LUN with the command:
   
   ESXi 5.0: # esxcli storage core claimrule add --rule <number> -t location -A <hba_adapter> -C <channel> -T <target> -L <lun> -P MASK_PATH
   
   ESX/ESXi 4.x: # esxcli corestorage claimrule add --rule <number> -t location -A <hba_adapter> -C <channel> -T <target> -L <lun> -P MASK_PATH
   
   The parameters -A <hba_adapter> -C <channel> -T <target> -L <lun> define a unique path. You can leave some of them unspecified if the LUN is uniquely defined. The value for parameter --rule can be any number between 101 and 200 that does not conflict with a pre-existing rule number from step 3.
   
   Note: For a detailed command description, see esxcli corestorage Command-Line Options and vSphere Command-Line Interface Installation and Scripting Guide.
   
   This is a brief example of usage:
   
   
   • Find the naa device of the datastore you want to unpresent with the command:
     
     # esxcfg-scsidevs -m
     naa.600508b1001037383941424344450300:3 /vmfs/devices/disks/naa.600508b1001037383941424344450300:3 4b44572e-8a1c74b2-42d4-00237dde59b8 0 datastore1
     naa.600601604550250018ea2d38073cdf11:1 /vmfs/devices/disks/naa.600601604550250018ea2d38073cdf11:1 4bb21500-dc941493-2904-00237dde59ba 0 DatastoreToMask
     
   • Check all of the paths that the naa device has:
     
     # esxcfg-mpath -b -d naa.600601604550250018ea2d38073cdf11
        vmhba33:C0:T3:L0 state:active Local HBA vmhba33 channel 0 target 3
        vmhba33:C0:T2:L0 state:standby Local HBA vmhba33 channel 0 target 2
        vmhba33:C0:T1:L0 state:active Local HBA vmhba33 channel 0 target 1
        vmhba33:C0:T0:L0 state:standby Local HBA vmhba33 channel 0 target 0
     
   • As you apply the rule -A vmhba33 -C 0 -L 0, verify that there is no other device with those parameters. You can use the wildcard vmhba33:C0.*L0 (. means any character and * means zero or more times).
     
     # esxcfg-mpath -L | egrep "vmhba33:C0.*L0"
     vmhba33:C0:T3:L0 state:active naa.600601604550250018ea2d38073cdf11 vmhba33 0 3 0 NMP active san iqn.1998-01.com.vmware:cs-tse-h42-17d4ba81 00023d000001,iqn.1992-04.com.emc:cx.ckm00092300229.b2,t,4
     vmhba33:C0:T2:L0 state:standby naa.600601604550250018ea2d38073cdf11 vmhba33 0 2 0 NMP standby san iqn.1998-01.com.vmware:cs-tse-h42-17d4ba81 00023d000001,iqn.1992-04.com.emc:cx.ckm00092300229.a3,t,3
     vmhba33:C0:T1:L0 state:active naa.600601604550250018ea2d38073cdf11 vmhba33 0 1 0 NMP active san iqn.1998-01.com.vmware:cs-tse-h42-17d4ba81 00023d000001,iqn.1992-04.com.emc:cx.ckm00092300229.b3,t,2
     vmhba33:C0:T0:L0 state:standby naa.600601604550250018ea2d38073cdf11 vmhba33 0 0 0 NMP standby san iqn.1998-01.com.vmware:cs-tse-h42-17d4ba81 00023d000001,iqn.1992-04.com.emc:cx.ckm00092300229.a2,t,1
     
   • Add a rule for this LUN with the command:
     
     ESXi 5.0: # esxcli storage core claimrule add --rule 192 -t location -A vmhba33 -C 0 -T 0 -L 0 -P MASK_PATH
     
     ESX/ESXi 4.x: # esxcli corestorage claimrule add --rule 192 -t location -A vmhba33 -C 0 -T 0 -L 0 -P MASK_PATH
     
     Notes:
     
     • For more information about the adapter, channel, target and LUN values, see Identifying disks when working with VMware ESX (1014953).
     • For more information about the command and its options, see Managing Claim Rules with esxcli corestorage claimrule in the vSphere Command-Line Interface Documentation.
       
5. Verify that the rule is in effect with the command:
   
   ESXi 5.0: # esxcli storage core claimrule list
   ESX/ESXi 4.x: # esxcli corestorage claimrule list
   
   The output indicates our new rule. It is only of class file. You must then load it into the PSA.
   
   For example:
   
   Rule Class Type Plugin Matches
   0 runtime transport NMP transport=usb
   1 runtime transport NMP transport=sata
   2 runtime transport NMP transport=ide
   3 runtime transport NMP transport=block
   4 runtime transport NMP transport=unknown
   101 runtime vendor MASK_PATH vendor=DELL model=Universal Xport
   101 file vendor MASK_PATH vendor=DELL model=Universal Xport
   192 file location MASK_PATH adapter=vmhba33 channel=0 target=* lun=0
   65535 runtime vendor NMP vendor=* model=*
   
6. Reload your claimrules with the command:
   
   ESXi 5.0: # esxcli storage core claimrule load
   ESX/ESXi 4.x: # esxcli corestorage claimrule load
   
7. Re-examine your claimrules and verify that you can see both the file and runtime class. Run the command:
   
   ESXi 5.0: # esxcli storage core claimrule list
   ESX/ESXi 4.x: # esxcli corestorage claimrule list
   
   For example:
   
   Rule Class Type Plugin Matches
   0 runtime transport NMP transport=usb
   1 runtime transport NMP transport=sata
   2 runtime transport NMP transport=ide
   3 runtime transport NMP transport=block
   4 runtime transport NMP transport=unknown
   101 runtime vendor MASK_PATH vendor=DELL model=Universal Xport
   101 file vendor MASK_PATH vendor=DELL model=Universal Xport
   192 runtime location MASK_PATH adapter=vmhba33 channel=0 target=* lun=0
   192 file location MASK_PATH adapter=vmhba33 channel=0 target=* lun=0
   65535 runtime vendor NMP vendor=* model=*
   
8. Unclaim all paths to a device and then run the loaded claimrules on each of the paths to reclaim them.
   
   Note: Unclaiming disassociates the paths from a PSA plugin. These paths are currently owned by NMP. You need to dissociate them from NMP and associate them to MASK_PATH.
   
   Run the command:
   
   ESXi 5.0: # esxcli storage core claiming reclaim -d naa.id
   ESX/ESXi 4.x: # esxcli corestorage claiming reclaim -d naa.id
   
   Where naa.id is the naa ID used in step 3. This device is the LUN being unpresented. This command attempts to unclaim all paths to a device and runs the loaded claimrules on each of the paths unclaimed to attempt to reclaim them.
   
   For example:
   
   ESXi 5.0: # esxcli storage core claiming reclaim -d naa.600601604550250018ea2d38073cdf11
   ESX/ESXi 4.x: # esxcli corestorage claiming reclaim -d naa.600601604550250018ea2d38073cdf11
   
9. Verify that the masked device is no longer used by the ESX host.
   
   If you are masking a datastore, perform one of these options:
   
   
   • Connect the vSphere Client to the host and click Host > Configuration > Storage, then click Refresh. The masked datastore does not appear in the list.
     
   • Rescan the host by navigating to Host > Configuration > Storage Adapters > Rescan All.
     
   • Run the command:
     
     # esxcfg-scsidevs -m
     
     The masked datastore does not appear in the list.
     
     To see all the masked LUNs use the command:
     
     # esxcfg-scsidevs -c
   
   To verify that a masked LUN is no longer an active device, run the command:
   
   # esxcfg-mpath -L | grep naa.id
   
   For example:
   
   # esxcfg-mpath -L | grep 600601604550250018ea2d38073cdf11
   
   Empty output indicates that the LUN is not active.

Note: You may still see a single path to the LUN on one or more storage adapters after following the steps in this article. This disappears after the ESX host is rebooted. As long as the datastore is no longer visible, no issues are being reported in the logs, and rescans are completing in a timely fashion, the residual path can be safely ignored.

For more/related information, see Unable to claim the LUN back after unmasking it (1015252).

Source:- 

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1009449

Change vNUMA Settings

By default, vNUMA is enabled only for virtual machines with more than eight vCPUs. This feature can

be enabled for smaller virtual machines, however, by adding to the .vmx file the line:

numa.vcpu.maxPerVirtualNode =  X

(where  X is the number of vCPUs per vNUMA node).

NOTE    

        Some multi-core processors have  NUMA node sizes that are different than the number of cores

per socket. For example, some 12- core processors have two six- core NUMA nodes per processor.

NOTE    

         This change can be made through the vSphere Client:

1 Select the virtual machine you  wish to change, then click Edit virtual machine settings.

2 Under the  Options tab, select  General, then click  Configuration Parameters .

3 Look for numa.vcpu.maxPerVirtualNode. If it’s not present, click  Add Row and enter the new

variable.

4 Click on the value to be changed and configure it as you wish.

ESXi5 Partition Layout

During the installation of ESXi 5.0, the system creates at least five partitions whose size and layout the user cannot control.

You can use the command “ls /dev/disks/ -l” to display all the created partitions:

These are those Partitions:

Detailed Explanation of these Partitions is given below


Bootpartition (4 MB):
This partition is needed for booting

Bootbank (250 MB):
The compressed boot image is saved on this FAT partition.
It will be extracted during the boot process and loaded into the system memory.

At the time of vSphere 4 this file had a size of about 70 MB, with vSphere 5 it is now grown to 250 MB.
AltBootbank (250 MB):
This partition is empty after a fresh install. Once you perform an update of ESXi, the current image is copied from the bootbank partition here.
This makes it possible to return to the last known good configuration by typing “Shift + R” while booting if there occures an error during the update of an ESXi host.

Dump/crash partition (110 MB):
In the case of a total crash of the host a dump file is written on this partition.

Store (285 MB):
On this partition the different ISO files for the VMWare Tools are available for all supported operating systems.

Scratch partition (4 GB):
This partition is only created if the installation media has at least 5 GB of space. It is used for the log files of the VMKernel.
If this partition is missing, the logs of the host are lost after a reboot or shutdown.

VMFS partition:
This partition is only created if the installation medium is not a flash memory.
It extends over the total available space of the medium and is formatted with VMFS 5.

Vmware Tools Path on ESXi

1. Enable the SSH on ESXi and Connect with ESXi through Putty.

2. Enter the Login Credentials to Login

3. Enter this Command:-
cd /store/packages/5.0.0./vmtools and Hit Enter Key

4. Run Ls -l command to list all the files and folders in this directory

For more info on this location /vmfs/volumes/........ check this article

How To Configure ESXi Shell Timeout

The ESXi Shell timeout setting specifies how long, in minutes, you can leave an unused session open. By default, the timeout for the ESXi Shell is 0, which means the session remains open even if it is unused. If you change the timeout, for example, to 30 minutes, you have to log in again after the timeout period has elapsed.

     First Method:-

To modify the ESXi Shell Timeout:

1.      In the Direct Console, follow these steps.

2.      Select Modify ESXi Shell timeout and press Enter.

3.      Enter the timeout value in minutes and press Enter.

Second Method:-

In the vSphere Client, follow these steps:

1.      In the Configuration tab’s Software panel, click Advanced Settings.

2.      In the left panel, click UserVars.

3.      Find UserVars.ESXiShellTimeOut and enter the timeout value in minutes.

4.      Click OK.