Home > Blogs > VMware vSphere Blog > Tag Archives: advanced settings

Tag Archives: advanced settings

Should I use das.failuredetectiontime or das.config.fdm.isolationPolicyDelaySec

Today I received a question around the use of das.failuredetectiontime and das.config.fdm.isolationPolicyDelaySec. Should you be using these advanced settings?

Short answer: no.

Long answer: This myth has been floating around for a long long time. Many people were under the impression that das.failuredetectiontime needed to be configured when you started adding additional isolation addresses.This is not the case!

I just received an email with the question if the same applied to vSphere 5.1 now that “das.config.fdm.isolationPolicyDelaySec” was introduced as a replacement for das.failiredetectiontime. The answer remains “no you should not be using this. Unless, unless there are specific networking requirements to do so. There is absolutely no need to increase the failure detection time / isolation policy delay when multiple isolation addresses are configured. Isolation addresses are pinged in parallel, which means no additional time is needed to complete this process.

In summary, it is not recommended to use these advanced settings unless you have specific networking requirements to do so.

Identifying Non-Default Advanced & Kernel Settings Using ESXCLI 5.1

I recently came across a very cool tidbit from one of our GSS Engineers Daniel de Sao Jose about a new option in ESXCLI 5.1 which allows you to list out all ESXi advanced and kernel settings that have non-default values configured. This can come in handy when you are troubleshooting and trying to find out what advanced settings were changed on a host or if you need to capture the list of changes for documentation purposes or for creating a script to apply to other hosts.

To list all ESXi Advanced Settings, you would run the following command (4.x & 5.x):

esxcli system settings list

To list only ESXi Advanced Settings that have changed from the system defaults, there is now a new option called [ --delta | -d ] in ESXCLI 5.1 which can be specified with the list operation (ESXi 5.1 only):

esxcli system settings advanced list -d

Path: /UserVars/SuppressShellWarning
Type: integer
Int Value: 1
Default Int Value: 0
Min Value: 0
Max Value: 1
String Value:
Default String Value:
Valid Characters:
Description: Don’t show warning for enabled local and remote shell access

In the example above, we can see that the /UserVars/SuppressShellWarning setting has been changed from the system default of 0 (false) to 1 (true).

To list all ESXi Kernel Settings, you would run the following command (4.x & 5.x):

esxcli system settings advanced kernel list

To list only ESXi Kernel Settings that have changed from the system defaults, there is also a new option called [ --delta | -d ] in ESXCLI 5.1 which can be specified with the list operation (ESXi 5.1 only):

esxcli system settings advanced kernel list -d

Name                  Type   Description                 Configured  Runtime  Default
—————        —-    ————————-  ———-     ——-      ——-
smallFontForTTY  Bool  Use 50-line font for tty.  true           FALSE     FALSE

In the example above, we can see that the smallFontForTTY setting has been changed from the system default of false to true.

The next time you are stuck wondering what ESXi Advanced or Kernel settings you might have changed, you now have a very easy way of figuring out the specific settings and their configured value and defaults.

Get notification of new blog postings and more by following lamw on Twitter:  @lamw

Acessing Virtual Machine Advanced Settings

By William Lam, Sr. Technical Marketing Engineer

From time to time I get questions on how to access the advanced settings for a virtual machine and how to go about searching for the settings using the VM’s .vmx configuration file. Though the advanced settings are stored in the .vmx configuration file, they can also be accessed and viewed using the vSphere Client.

Adv-setting-1

These advanced settings are stored as a key/value pair and is primarily used by VMware to add additional information or configurations to a specific VM. These settings are persistent throughout the life of the VM, even when you clone the VM, the settings are also copied. One example of where this is used, is with VMware’s vShield product. Advanced settings are used in vShield Manager and vShield App VM to help identify their role and actions within the vShield solution.

If you wish to list all the advanced settings for a VM, you can easily automate this with the help of the vSphere API. As part of the VM’s configuration, there is a property in the vSphere API called extraConfig, which is an array that contains the key/value pair settings.

Here is an example of listing the advanced settings for a VM using the vSphere SDK for Perl script called vmAdvSettings.pl:

$ ./vmAdvSettings.pl –server vcenter50-3 –username root –vmname MyVM –operation list

Key: ethernet0.filter0.param0   Value: vshield-dvfilter-module
Key: ethernet0.filter0.param1   Value: uuid=5019b662-a14c-8166-9ce3-61f362de05a3.000
Key: evcCompatibilityMode       Value: FALSE
Key: guestCPUID.0       Value: 0000000b756e65476c65746e49656e69
Key: guestCPUID.1       Value: 000106a400010800809822010febfbff
Key: guestCPUID.80000001        Value: 00000000000000000000000128100800
Key: hostCPUID.0        Value: 0000000b756e65476c65746e49656e69
Key: hostCPUID.1        Value: 000106a400010800809822210febfbff
Key: hostCPUID.80000001 Value: 00000000000000000000000128100800
Key: hpet0.present      Value: true
Key: migrate.hostLogState       Value: none
Key: migrate.migrationId        Value: 0
Key: nvram      Value: MyVM.nvram
Key: replay.supported   Value: false
Key: scsi0.pciSlotNumber        Value: 16
Key: snapshot.action    Value: keep
Key: uuid.action        Value: create
Key: virtualHW.productCompatibility     Value: hosted
Key: vmci0.pciSlotNumber        Value: 32
Key: vmotion.checkpointFBSize   Value: 4194304
Key: vmware.tools.installstate  Value: none
Key: vmware.tools.internalversion       Value: 2147483647
Key: vmware.tools.lastInstallStatus     Value: unknown
Key: vmware.tools.requiredversion       Value: 8384

You can also query a specific advanced setting if you already know the key. Here is an example by specifying –key parameter:

$ ./vmAdvSettings.pl –server vcenter50-3 –username root –vmname MyVM –operation list –key ethernet0.filter0.param1

Key: ethernet0.filter0.param1   Value: uuid=5019b662-a14c-8166-9ce3-61f362de05a3.000

Here is an example of listing the advanced settings for a VM using PowerCLI:

Note: The functions used in this PowerCLI example can be found here and should be added to your session first.

Get-VM MyVM | Get-VMAdvancedConfiguration

Key                                                   Value
—                                                   —–
ethernet0.filter0.param0                              vshield-dvfilter-module
ethernet0.filter0.param1                       uuid=5019b662-a14c-8166-9ce3-61f362de05a3.000
guestCPUID.0                                          0000000568747541444d416369746e65
guestCPUID.1                                          00100f230000080080802001078bfbff
guestCPUID.80000001                                   00100f231000036f000001e9ebd3fbff
userCPUID.0                                           0000000568747541444d416369746e65
userCPUID.1                                           00100f230004080080802001078bfbff
userCPUID.80000001                                    00100f231000036f000001e9ebd3fbff
evcCompatibilityMode                                  false                           
config.readOnly                                       false                           
replay.filename
unity.wasCapable                                      false                           
checkpoint.vmState                              
replay.allowFT                                        false             &#0
160;             

vshield.vmtype                                        Manager                         
vshield.vmversion                                     5.0                             
pciBridge5.present                                    true                            
vshield.vmbuild                                       473791                          
a57d4b11.vswp
scsi0:1.ctkEnabled                                    true                                                        
vmware.tools.internalversion                          8384                            
vmware.tools.requiredversion                          8384                            
vmware.tools.installstate                             none                            
vmware.tools.lastInstallStatus                        unknown                         
migrate.hostLogState                                  none                            
migrate.migrationId                                   0  

You can also query a specific advanced setting using the PowerCLI functions if you already know the key. Here is an example by specifying -key parameter:

Get-VM MyVM | Get-VMAdvancedConfiguration -Key “ethernet0.filter0.param1”

Key                                    Value
—                                    —–
ethernet0.filter0.param1               uuid=5019b662-a14c-8166-9ce3-61f362de05a3.000

As I mentioned earlier, VMware is the primary consumer of the advanced settings, but did you know, it is also available for everyone to use? It is just as easy to query for the settings as it is to add your own custom key/value pair by using the vSphere API UpdateOptions method.

Here is an example of using the vSphere SDK for Perl script:

./vmAdvSettings.pl –server vcenter50-3 –username root –vmname MyVM –operation update –key asset.tag –value ABC123

Reconfiguring “MyVM” with advanced setting: “asset.tag = ABC123″ …
Successfully updated advanced setting for “MyVM”!

Here is an example of using PowerCLI:

Get-VM MyVM | Set-VMAdvancedConfiguration -Key “asset.tag” -value ABC123

Set Advanced configuration for MyVM: asset.tag = ABC123

If you are using vCenter Server, there is also a feature called Custom Attributes which provides a similar mechanism to add custom fields but is applicable to both a VM and/or ESX(i) host. These custom fields also persist throughout the life of a VM and ESX(i) host, but the only difference is these settings are stored in the vCenter database and not with the actual VM or ESX(i) objects. You can view these custom fields in the VM and ESX(i) column tabs in your vCenter Server.

Screen Shot 2012-03-05 at 3.55.56 PM

It is recommended that you use the custom attributes as a way to centrally manage and create custom fields for your VM and ESX(i) hosts. This allows for the data to be centralized in your vCenter Server and you do not need to worry about individual VM configurations.

Additional Resources:

  • vSphere SDK for Perl script to help create/automate VM custom attributes.
  • PowerCLI can be used to automate custom attributes as seen here.

Get notification of new blog postings and more by following lamw on Twitter:  @lamw

iSCSI Advanced Settings

I've had a few questions recently about some of the iSCSI configuration parameters found in the Advanced Settings.

Iscsi-advanced

When iSCSI establishes a session between initiator and target, it has to login to the target. It will try to login for a period of LoginTimeout. If that exceeds, the login fails.

When iSCSI finishes a session between initiator and target, it has to logout of the target. It will try to logout for a period of LogoutTimeout. If that exceeds, the logout fails.

The other options relate to how we determine a DEAD PATH:

  1. RecoveryTimeout is used to determine how long we should wait before placing a path into a DEAD_STATE when the path was active, but now no PDUs are being sent or received. Realistically it’s a bit longer than that, as other considerations are taken into account as well.
  2. The noop settings are used to determine if a path is dead, when it is not the active path. iSCSI  will passively discover if this path is dead by using the noop timeout. This test is carried out on non-active paths every NoopInterval, and if a response isn’t received by NoopTimeout, the path is marked as DEAD.

Unless you wanted faster failover times, you probably wouldn't ever need to edit these. But be careful because if you have paths failing too quickly and then recovering, you could have LUNs/devices moving unnecessarily between array controller targets which could lead to path thrashing.

Get notification of these blogs postings and more VMware Storage information by following me on Twitter: Twitter @VMwareStorage