ESXi/ESX host disconnects from vCenter Server after adding or connecting it to the inventory (2040630)

Symptoms

• An ESXi/ESX host disconnects from vCenter Server.
• After adding or reconnecting an ESXi/ESX to the vCenter Server inventory, it disconnects 30 to 90 seconds after the task completes.
• Changing the uplink switch port VLAN information for the new IP of the ESXi host before changing the IP of the ESXi host results in the host showing as disconnected in vCenter Server.
• Changing the IP address of the ESXi host using the DCUI without first removing the host from the vCenter Server inventory results in the host showing up as disconnected in vCenter Server.

Purpose

This article helps identify issues with heartbeat traffic between vCenter Server and ESXi/ESX hosts.

The steps provided in this article and the included Knowledge Base article links help determine if heartbeat packets are being dropped or lost.

Cause

This issue is caused by dropped, blocked, or lost heartbeat packets between the vCenter Server and the ESXi/ESX host.

If there is an incorrect configuration of the vCenter Server managed IP address, the host receives the heartbeat from vCenter Server but cannot return it.

It is important to remember that the default heartbeat port is UDP 902, and these packets must be sent between vCenter Server and the ESXi/ESX host for the host to stay connected and remain in the vCenter Server inventory.

If the host is not connecting to vCenter Server at all, the cause may be another network issue.

Resolution

To troubleshoot this issue, ensure that bidirectional heartbeat communications are functioning correctly.

The default port for this communication is UDP 902, but be sure to verify the configured port in the vpxa.cfg file on the host. This file also defines the IP address which manages the host.

Confirm vCenter Server managed IP address

Confirm the vCenter Server managed IP address continuity throughout the environment.

1. Determine the managed IP address of the vCenter Server:
   
   
   1. Connect to the vCenter Server with the vSphere Client.
   2. Go to Administration > vCenter Server Settings > Advanced Settings.
   3. Make note of the IP address in the ManagedIP row.
      
2. Determine the IP address configured for vCenter Server:
   
   
   1. From a console or RDP session to the vCenter Server desktop, open a command prompt.
   2. Run the command:
      
      ipconfig
      
   3. Make note of the IP address and ensure that it matches the managed IP address found in step 1.
      
3. Determine the IP address and port that the ESXi/ESX host is using for heartbeat traffic:
   
   
   1. Connect to the ESXi/ESX host using the vSphere Client.
   2. When the Warning pop-up appears, make note of the IP address which is managing the host.
   3. Connect to the same host using SSH.
   4. Check the vpxa.cfg file for the heartbeat traffic port by running the command:
      
      
      • On ESXi 5.x:
        
        grep -i serverport /etc/vmware/vpxa/vpxa.cfg
        
      • On ESXi/ESX 4.1 and earlier:
        
        grep -i serverport /etc/opt/vmware/vpxa/vpxa.cfg
        
   5. Ensure that the port number matches the default heartbeat port of 902.
   6. Check the vpxa.cfg file for the managed IP address by running the command:
      
      
      • On ESXi 5.x:
        
        grep -i serverIp /etc/vmware/vpxa/vpxa.cfg
        
      • On ESXi/ESX 4.1 and earlier:
        
        grep -i serverIp /etc/opt/vmware/vpxa/vpxa.cfg
        
   7. Ensure that the IP address matches the managed IP address found in step 1.

Connectivity

Test connectivity between vCenter Server and the ESXi/ESX host via the heartbeat network.

Using telnet and netcat, test connectivity over the heartbeat network via the configured heartbeat port (default 902). For more information, see:

• Troubleshooting network and TCP/UDP port connectivity issues on ESXi/ESX (2020669)
• TCP and UDP Ports required to access vCenter Server, ESXi/ESX hosts, and other network components (1012382)

Congestion

Test network congestion:

• To test whether UDP heartbeat packets are being received by vCenter Server within the 60-second timeout period, seeESXi/ESX host disconnects from vCenter Server 60 seconds after connecting (1029919).
• If packets are delayed due to network congestion, see ESXi/ESX host keeps disconnecting and reconnecting when heartbeats are not received by vCenter Server (1005757).
• If NAT is configured, see ESXi hosts connected to vCenter Server using NAT disconnect after 30 to 60 seconds (2019865).

Other troubleshooting areas

• Check the NIC firmware and driver levels on the affected host and compare these with other hosts. For more information, see Determining Network/Storage firmware and driver version in ESXi/ESX 4.x and 5.x (1027206).
• Check the Address Resolution Protocol and Neighbor Discovery cache for inconsistencies. For more information, seeDisplaying the ARP and Neighbor Discovery cache for VMkernel network interfaces (2000130).
• Capture a network trace and analyze for inconsistency. For more information, see Capturing a network trace in ESXi using Tech Support Mode or ESXi Shell (1031186).

Additional Information

For more information on the vpxa.cfg file, see ESXi 5.0 hosts are marked as Not Responding 60 seconds after being added to vCenter Server (2020100).

For more information on similar issues, see:

• vCenter Server IP address change causes ESX hosts to disconnect (1001493)
• Verifying the vCenter Server Managed IP Address (1008030)

Source:-

http://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC&docType=kc&docTypeID=DT_KB_1_1&externalId=2040630

ESXi/ESX host disconnects from vCenter Server 60 seconds after connecting (1029919)

Symptoms

• An ESXi/ESX host is successfully added to the vCenter Server inventory but enters a Not Responding or Disconnectedstate after one minute.
• You can use the vSphere Client to successfully connect to the ESXi/ESX host directly.
• In the vpxd.log file, you see entries similar to:
  
  2012-04-02T13:07:49.438+02:00 [02248 info 'Default' opID=66183d64] [VpxLRO] -- BEGIN task-internal-252 -- -- vim.SessionManager.acquireSessionTicket -- 52fa8682-47e0-2566-fb05-6192cb2c22f9(5298e245-ffb6-f7f8-e8a0-dedfbe369255)
  2012-04-02T13:07:49.579+02:00 [02068 info 'Default'] [VpxLRO] -- BEGIN task-internal-253 -- host-94 -- VpxdInvtHostSyncHostLRO.Synchronize --
  2012-04-02T13:07:49.579+02:00 [02068 warning 'Default'] [VpxdInvtHostSyncHostLRO] Connection not alive for host host-94
  2012-04-02T13:07:49.579+02:00 [02068 warning 'Default'] [VpxdInvtHost::FixNotRespondingHost] Returning false since host is already fixed!
  2012-04-02T13:07:49.579+02:00 [02068 warning 'Default'] [VpxdInvtHostSyncHostLRO] Failed to fix not responding host host-94
  2012-04-02T13:07:49.579+02:00 [02068 warning 'Default'] [VpxdInvtHostSyncHostLRO] Connection not alive for host host-94
  2012-04-02T13:07:49.579+02:00 [02068 error 'Default'] [VpxdInvtHostSyncHostLRO] FixNotRespondingHost failed for host host-94, marking host as notResponding
  2012-04-02T13:07:49.579+02:00 [02068 warning 'Default'] [VpxdMoHost] host connection state changed to [NO_RESPONSE] for host-94
  2012-04-02T13:07:49.610+02:00 [02248 info 'Default' opID=66183d64] [VpxLRO] -- FINISH task-internal-252 -- -- vim.SessionManager.acquireSessionTicket -- 52fa8682-47e0-2566-fb05-6192cb2c22f9(5298e245-ffb6-f7f8-e8a0-dedfbe369255)
  2012-04-02T13:07:49.719+02:00 [02068 info 'Default'] [VpxdMoHost::SetComputeCompatibilityDirty] Marked host-94 as dirty.

Cause

This issue may occur if heartbeat packets are not received from the host before the one minute timeout period expires. These heartbeat packets are UDP packets sent over port 902.

This issue may also occur when the Windows firewall is enabled and the ports are not configured.

Resolution

To resolve this issue, check the Windows Firewall on the vCenter Server machine. If ports are not configured, disable the Windows Firewall.

If ports are configured, verify if network traffic is allowed to pass from the ESXi/ESX host to the vCenter Server system, and that it is not blocking UDP port 902.

To perform a basic verification from the guest operating system perspective:

1. Click Start > Run, type wf.msc, and click OK. The Windows Firewall with Advanced Security Management console appears.
2. In the left pane, click Inbound Rules.
3. Right-click the VMware vCenter Server -host  heartbeat rule and click Properties.
4. In the Properties dialog, click the Advanced tab.
5. Under Profiles, ensure that the Domain option is selected.

You can use Wireshark to verify if the network allows bi-directional traffic.

Note: VMware does not endorse or recommend any particular third-party utility.

To verify if bi-directional traffic is allowed:

1. Download Wireshark from http://www.wireshark.org/ and install it on the vCenter Server system.
2. On ESXi, enable Tech Support Mode. For more information on enabling Tech Support Mode, see:
   
   
   • For ESXi 4.1 and 5.x: Using Tech Support Mode in ESXi 4.1 and ESXi 5.x (1017910)
   • For ESXi 4.0: Tech Support Mode for Emergency Support (1003677)
3. Download the Python script attached to this article (udp_client.py) to the ESXi/ESX system in question.
4. Edit the udp_client.py script on the ESXi/ESX host with a text editor. Modify the line, "host = '192.168.1.1'" and replace 192.168.1.1 with the IP address of the vCenter Server system.
5. Start Wireshark on the vCenter Server system.
   
   
   1. In the Filter field, enter ip.src==IP_of_host and udp.port==902. Replace IP_of_host with the IP address of the ESXi/ESX host in question.
   2. Click Apply.
   3. From the Capture menu, select Interfaces and click Start next to the NIC used for vCenter Server IP traffic.
      
6. From the ESXi/ESX host, run this command:
   
   python udp_client.py
   
   The total number of packets sent, the port, and the destination address are displayed.
   
7. On the vCenter Server system, watch the Wireshark screen for any packets showing up that match the filter applied.
8. If no packets are received, this indicates that something is blocking UDP traffic over port 902 from the ESXi/ESX host to the vCenter Server system. Inspect the physical networking environment and any software-based firewall on the vCenter Server system.

Ensure that these ports are open in the firewall between vCenter Server and the ESXi/ESX hosts:

• 902 - UDP & TCP
• 443 - TCP

For more information, see TCP and UDP Ports required to access vCenter Server, ESX hosts, and other network components (1012382).

Additional Information

This article does not assist you in troubleshooting ESXi 3.5 hosts that are disconnecting from vCenter Server after one minute as a Python interpreter is not installed on ESXi 3.5.

For more information on a similar issue, see ESXi/ESX host disconnects from vCenter Server after adding or connecting it to the inventory (2040630).

Source:-

http://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC&docType=kc&docTypeID=DT_KB_1_1&externalId=1029919

Repointing and reregistering VMware vCenter Server 5.1.x and components(2033620)

I was getting this message and I resolved this Issue by using this KB Article. This might be helpful for all of you as well

Details

After certain changes to your vSphere deployment topography, you might need to repoint or reregister vCenter Server components with the vCenter Inventory Service or vCenter Single Sign-On and the vCenter Lookup Service to ensure that the components can continue to communicate.

Caution: The procedures in this article are supported by VMware only when used with the guidance of VMware Technical Support.

If a vCenter Single Sign-On instance fails or is corrupted, any associated vCenter Servers, Inventory Service instances, and vSphere Web Client instances lose access to vSphere. In this case, you have several options:

• If you do not have another Single Sign-On instance, you can create a new Single Sign-On instance.
• If your Single Sign-On instance is corrupted, and you have a current, uncorrupted backup of the Single Sign-On database and configuration, you can restore Single Sign-On to a new host machine. For information about creating, backing up, or restoring a Single Sign-On instance, see the vSphere 5.1 Installation and Setup Guide on the VMware vSphere Documentation page.
• If your deployment has another Single Sign-On instance, you can repoint vCenter Server components to that instance.

Similarly, when you relocate a vCenter Server instance or make certain changes to the vCenter Inventory Service, you must reregister vCenter Server with vCenter Inventory Service.

Solution

If you are responding to a failed Single Sign-On instance, perform the procedures in this order:

1. Remove the Inventory Service account
   
   Note: This is required only if you are reregistering the vCenter Inventory Service to the same Single Sign-On instance that the vCenter Inventory Service was originally registered to.
2. Reregister vCenter Inventory Service with vCenter Single Sign-On
3. Register vCenter Server with a different vCenter Single Sign-On instance
4. Reregister vCenter Server with the Inventory Service
5. Register the vSphere Web Client with a different vCenter Single Sign-On instance

Remove the Inventory Service account

This procedure is required only if you reregister vCenter Inventory Service to the same Single Sign-On instance that Inventory Service was originally registered to. When you reregister Inventory Service to the same Single Sign-On instance, you must first remove the Inventory Service account from the Single Sign-On application users. Otherwise, the reregistration will fail with the error, AlreadyRegistered.

To remove the Inventory Service account:

1. In the vSphere Web Client, go to Administration.
2. In SSO Users and Groups, click Application Users.
3. Delete the Inventory Service account.

Reregister vCenter Inventory Service with vCenter Single Sign-On

During vCenter Inventory Service installation or upgrade, the Inventory Service is registered with a vCenter Single Sign-On instance, and the Inventory Service stores the location of the vCenter Single Sign-On instance. When you relocate a vCenter Single Sign-On instance or switch to a different Single Sign-On instance, update the corresponding Inventory Service instance. If a Single Sign-On instance fails or is corrupted, you can also use this procedure to repoint the Inventory Service to a different Single Sign-On instance.

If changes occur to any of these entities, reregister the Inventory Service with vCenter Single Sign-On using:

• IP address of the vCenter Single Sign-On instance
• vCenter Inventory Service host DNS or IP address
• vCenter Inventory Service certificates

Note: If you are reregistering the Inventory Service to the same Single Sign-On instance, you must first remove the Inventory Service account from the Single Sign-On application users. For more information, see the Remove the Inventory Service account section. 
To reregister the Inventory Service with vCenter Single Sign-On:

1. Open a command prompt on the Inventory Service host machine.
2. Change directory to:
   
   C:\Program Files\VMware\Infrastructure\Inventory Service\scripts
   
   Note: If you installed vCenter Inventory Service in a different location from the default C:\Program Files\, adjust the path.
   
   Note: Typically, short names are not disabled. However, if you have disabled short names on your system, or have removed short names for the folder where the Inventory Service and vCenter Server are installed, follow these steps:
   
   
   1. Open the regTool.cmd file with a text editor. The regTool.cmd file is located at:
      
      installation_path\Inventory Service\sso
   2. In the line beginning with set LOG4J_CONF=, enclose %TOOLDIR% in quotations marks:
      
      "%TOOLDIR%"
   3. Save and close the file.
3. Run the is-change-sso.bat command to update the stored configuration information of the Inventory Service:
   
   is-change-sso.bat ssoServerUrl "ssoAdminuser" "ssoAdminPassword"
   
   Use this example as a model:
   
   is-change-sso.bat https://machinename.corp.com:7444/lookupservice/sdk "admin@System-Domain" "SSO_pw1!"
   
   In this example, 7444 is the default HTTPS port number for vCenter Single Sign-On. If you use a custom port, replace the port number in the example with the port number you use. The quotation marks are required to escape special characters in the Single Sign-On user name and password.
4. Restart the Inventory Service:
   
   net stop vimQueryService
net start vimQueryService

The vCenter Inventory Service URL configuration is now updated and the Inventory Service is reregistered with vCenter Single Sign-On.

Note: If you are reregistering the Inventory Service to the same Single Sign-On instance, you must also reregister vCenter Server with the Inventory Service. For more information, see the Reregister vCenter Server with the Inventory Service section.

Register vCenter Server with a different vCenter Single Sign-On instance

During installation or upgrade, vCenter Server is registered with the Lookup Service for a vCenter Single Sign-On instance. You can change this registration to the Lookup Service for a different Single Sign-On instance. You might register vCenter Server to a different vCenter Single Sign-On instance if the original Single Sign-On instance fails, or if you add a new Single Sign-On node and want to associate vCenter Server with the new node.

Note: When you register vCenter Server to a new Single Sign-On instance, you lose these permissions:

• All permissions created for users from the Single Sign-On system identity source
• All permissions granted to users from identity sources that are not present in the new Single Sign-On instance
• All permissions granted to local operating system users

To register vCenter Server to a different vCenter Single Sign-On instance:

1. Open a command prompt on the vCenter Server host machine as administrator.
2. Change directory to:
   
   C:\Program Files\VMware\Infrastructure\VirtualCenter Server\ssoregtool
   
   Note: If you have installed vCenter Server in a location other than the default C:\Program Files\ folder, adjust the path. Also, in the repoint.cmd file, ensure that JAVA_HOME points to the correct location of your vCenter Server installation.
3. Unzip the sso_svccfg.zip file.
   
   Note: Best practice is to unzip these files into a new folder and change directory to the new folder before executing the next step.
4. Run this command to register vCenter Server to a different Single Sign-On instance:
   
   repoint.cmd configure-vc --lookup-server lookup_service_url --user single_sign_on_admin_user --password single_sign_on_admin_password --openssl-path "path_to_OpenSSL_bin_directory/"
   
   Note: If you installed vCenter Server in a location other than the default, you must add this option to the repointcommand:
   
   --vc-install-dir "path_to_vCenter_Server_install_directory"
   
   The openssl-path path must be enclosed in quotation marks and followed by a trailing forward slash. The openssl-path parameter is required to update the trust store with the new Lookup Service and Single Sign-On certificates. If you do not provide it, the command will execute successfully, but you must manually update the certificate trust store. See the information about updating the certificate trust store for vCenter components in the VMware tech note, Replacing Default vCenter 5.1 and ESXi Certificates.
   
   Use this example as a model:
   
   repoint.cmd configure-vc --lookup-server https://machinename.corp.com:7444/lookupservice/sdk --user "admin@System-Domain" --password "SSO_pw1!" --openssl-path "C:\Program Files\VMware\Infrastructure\Inventory Service\bin/"
   
   In this example, 7444 is the default HTTPS port number for vCenter Single Sign-On. If you use a custom port, replace the port number in the example with the port number you use. The quotation marks are required to escape special characters in the Single Sign-On user name and password.
   
   Notes:
   
   • If you receive the error The system cannot find the path specified, verify that the %JAVA_HOME% location in the repoint.cmd script (by default, set to: C:\Program Files\VMware\Infrastructure\jre) exists, is populated with data, and points to the correct JRE folder. If it is not, check for C:\Program Files\VMware\Infrastructure\jre1, and if this exists, update the script to point to the correct JAVA_HOMElocation and try the command again.
     
     For example, change:
     
     set CMD="%JAVA_HOME%\bin\java"
     to:
     
     set CMD="directory\Program Files\VMware\Infrastructure\jre\bin\java.exe" 
   • If you receive the error Abnormal command failure: exception `Cannot locate configuration source C:\Program Files\VMware\Infrastructure\VirtualCenter Server\ssoregt ool\vcsso.properties', create the folder structure C:\Program Files\VMware\Infrastructure\VirtualCenter Server\ssoregtool and copy thevcsso.properties file in to the ssoregtool folder.
5. Restart the VMware VirtualCenter Server and the VMware VirtualCenter Management Webservices services:
   
   
   1. In the Administrative Tools control panel, click Services.
   2. Right-click VMware VirtualCenter Server and click Restart.
   3. Right-click VMware VirtualCenter Management Webservices and click Restart.

The vCenter Server is now registered with the new Single Sign-On instance.

Reregister vCenter Server with the Inventory Service

During installation or upgrade, vCenter Server is registered with the vCenter Inventory Service, and the Inventory Service stores the location of vCenter Server. When you relocate a vCenter Server instance or make changes to the vCenter Inventory Service, you must update the corresponding Inventory Service instance.

Reregister the Inventory Service with vCenter Server if any of these entities change:

• vCenter Inventory Service certificate
• vCenter Server IP address or host name
• vCenter Inventory Service address or host name

You must also reregister vCenter Server with the Inventory Service if you reinstall the Inventory Service on the same machine and if any of these conditions apply:

• You overwrite the Inventory Service database during the reinstallation
• You reinstall the Inventory Service with a different path to the installation directory
• You change the Inventory Service port number

To reregister vCenter Server with the Inventory Service:

1. Open a command prompt.
2. Change directory to:
   
   C:\Program Files\VMware\Infrastructure\VirtualCenter Server\isregtool
   
   Note: If you installed the vCenter Inventory Service in a location other than the default C:\Program Files\, adjust the path.
3. Run the register-is.bat command to update the stored configuration information of the Inventory Service:
   
   register-is.bat vCenter_Server_URL Inventory_Service_URL Lookup_Service_URL
   
   Use this example as a model:
   
   register-is.bat https://machinename.corp.com:443/sdk https://machinename.corp.com:10443 https://machinename.corp.com:7444/lookupservice/sdk
   
   In this example, 443, 10443, and 7444 are the default HTTPS port numbers for vCenter Server, the Inventory Service, and vCenter Single Sign-On respectively. If you use custom ports, replace the port numbers in the example with the port numbers you use. The server FQDN should be used rather than an IP address for machinename.corp.com. If an IP address is used, you may see the SslHandshakeFailed=1 error.
4. Restart vCenter Server.

The vCenter Inventory Service URL configuration is now updated and vCenter Server is reregistered with the Inventory Service.

Register the vSphere Web Client with a different vCenter Single Sign-On instance

During installation or upgrade, the vSphere Web Client is registered with the Lookup Service for a vCenter Single Sign-On instance. If the Single Sign-On instance fails or changes, you might need to register the vSphere Web Client with a different vCenter Single Sign-On Lookup Service.

If the vCenter Single Sign-On server fails or is corrupted, you can install a new Single Sign-On instance and register the vSphere Web Client to the new Single Sign-On instance. Alternatively, you can install a new vSphere Web Client and register it to the new Single Sign-On instance. For more information, see the vSphere Installation and Setup documentation.

If you repoint vCenter Server and the vCenter Inventory Service from the failed Single Sign-On instance to a different, existing Single Sign-On instance, you can use the vSphere Web Client that is already registered with that Single Sign-On instance.

To register the vSphere Web Client with a different vCenter Single Sign-On Lookup Service:

1. Open a command prompt.
2. Change directory to:
   
   C:\Program Files\VMware\Infrastructure\vSphereWebClient\scripts
   
   Note: If you installed the vSphere Web Client in a location other than the default C:\Program Files\, adjust the path.
3. Run the client-repoint.bat command to register the vSphere Web Client with a different vCenter Single Sign-On and Lookup Service:
   
   client-repoint.bat lookup_service_url "single_sign_on_admin_user" "single_sign_on_admin_password"
   
   Use this example as a model:
   
   client-repoint.bat https://machinename.corp.com:7444/lookupservice/sdk "admin@System-Domain" "SSO_pw1!"
   
   In this example, 7444 is the default HTTPS port number for vCenter Single Sign-On. If you use a custom port, replace the port number in the example with the port number you use. The quotation marks are required to escape special characters in the Single Sign-On user name and password.

The vSphere Web Client is now registered with the vCenter Single Sign-On and Lookup Service.

Source:-

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

Unlocking and resetting the vCenter Single Sign On (SSO) administrator password (2034608)

Symptoms

• You are unable to log in to the vSphere Web Client using your SSO administrator credentials
• Logging in to the vSphere Web Client using your SSO administrator credentials fails 
• The password has been incorrectly entered three times (by default)
• You see the error:
  
  User account is locked. Please contact your administrator.

Cause

For security purposes, the administrator account is automatically locked out if there are too many failed login attempts. By default, vCenter SSO allows for three failed login attempts before an account is locked out.

Resolution

To resolve this issue, you must unlock/reset the administrator account. To reset the password, you must know the original password.

 

To unlock/reset the administrator account, use one of these methods:

• Wait for 15 minutes. By default, the account lockout policy is set to unlock after 15 minutes. For more information on account lockout policies for vCenter SSO, see Configuring and troubleshooting vCenter Single Sign On password and lockout policies for accounts (2033823).
  
• Unlock the account using another session that is still logged into the SSO server or using another user account with administrator privileges. 
  
  To unlock an account using another session or using another user account with administrator privileges:

1. Click Home.
2. Click Administration.
3. Click SSO Users and Groups.
4. Right-click the affected user account, such as admin, and click Unlock.
   

• In emergency situations or if the default policies have been changed, you can also reset the password to unlock the account.
  
  To reset the SSO administrator password on a Windows server:
  
  Note: Resetting the password will also unlock the administrator account.

1. Login as an administrator to the vCenter SSO server.
2. Click Start > Run, type cmd, and click OK. The Command Prompt window opens.
3. Navigate to the directory SSOInstallDirectory\utils. By default, the installation directory is C:\Program Files\VMware\Infrastructure\SSOServer\utils.
4. Run this command:
   
   rsautil reset-admin-password
5. Enter the master password when prompted.
   
   Note: This is the password selected for the SSO administrator during the SSO installation. If you have changed your SSO administrator password later, the master password is still the original one chosen.
   
6. Enter the SSO administrator name for which you want to reset the password. For example, admin.
7. Enter the new password for the user and then confirm it a second time.
   
   You should see the message Password reset successfully.

To reset the SSO administrator password on the vCenter Server Appliance:

1. Log in as root to the vCenter server Appliance. 
2. From the command line, navigate to /usr/lib/vmware-sso/utils directory. 
3. Run this command:
   
   ./rsautil reset-admin-password
4. Enter the master password when prompted.
   
   Note: By default, this is the root password.
   
5. Enter the SSO administrator name for which you want to reset the password. For example, admin.
6. Enter the new password for the user and then confirm it a second time.
   
   You should see the message Password reset successfully.

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

Understanding the vSphere Web Client Architecture

The vSphere Web Client architecture consists of a user interface layer and a service layer. Both layers reside on a Web application server, called the Virgo server. Each layer has a role in communicating with the vSphere environment, retrieving data, and presenting that data to the user’s Web browser.

User Interface Layer

The user interface layer consists of an Adobe Flex application that is displayed in the user’s Web browser. The Flex application contains all of the user interface elements with which the user interacts, such as menus, navigation elements, data portlets, and commands. The user can navigate through the various Flex elements in the user interface layer to view data on vSphere objects, send commands, and make changes to the vSphere environment.

The exact configuration of the elements in the user interface layer depends on the unique properties of the vSphere environment and other factors such as the level of privileges each user has.

Service Layer

The service layer is a collection of Java services that run in a framework on the vSphere Web Client application server, called the Virgo server. These Java services communicate with vCenter Server and other parts of the vSphere environment, as well as other remote data sources. The Java services gather monitoring data on the virtual infrastructure, which is in turn displayed to the user by the Flex user interface layer. When the user performs an action from the Flex user interface, such as a management or administration command, the Java services perform that command on the virtual infrastructure.

The vSphere Web Client application server contains a Spring framework that manages communication between the user interface layer and the service layer.

vSphere Web Client Architecture

Thanks to Vmware Documentation

Using DRS Affinity Rules

You can control the placement of virtual machines on hosts within a cluster by using affinity rules.

You can create two types of rules.

■

Used to specify affinity or anti-affinity between a group of virtual machines and a group of hosts. An affinity rule specifies that the members of a selected virtual machine DRS group can or must run on the members of a specific host DRS group. An anti-affinity rule specifies that the members of a selected virtual machine DRS group cannot run on the members of a specific host DRS group. See VM-Host Affinity Rules for information about creating and using this type of rule.

■

Used to specify affinity or anti-affinity between individual virtual machines. A rule specifying affinity causes DRS to try to keep the specified virtual machines together on the same host, for example, for performance reasons. With an anti-affinity rule, DRS tries to keep the specified virtual machines apart, for example, so that when a problem occurs with one host, you do not lose both virtual machines. See VM-VM Affinity Rules for information about creating and using this type of rule.

When you add or edit an affinity rule, and the cluster's current state is in violation of the rule, the system continues to operate and tries to correct the violation. For manual and partially automated DRS clusters, migration recommendations based on rule fulfillment and load balancing are presented for approval. You are not required to fulfill the rules, but the corresponding recommendations remain until the rules are fulfilled.

To check whether any enabled affinity rules are being violated and cannot be corrected by DRS, select the cluster's DRS tab and click Faults. Any rule currently being violated has a corresponding fault on this page. Read the fault to determine why DRS is not able to satisfy the particular rule. Rules violations also produce a log event.

Raw Device Mapping option is greyed out (1017704)

Symptoms

• You cannot create a raw device mapping (RDM).
• If you connect vSphere Client directly to an ESX host, the Raw Device Mappings option is greyed out.
  
  Note: To access the Raw Device Mappings option, right-click on a virtual machine, choose Edit Settings > Add Hard Disk > Raw Device Mappings
   
• If you navigate to Configuration > Storage adapters, you cannot see LUNs that are not used as VMFS volumes.
• If you navigate to Configuration > Storage > Add storage > Disk/LUN, you cannot see LUNs available in the list.

Resolution

The Raw Device Mapping (RDM) option is greyed out if:

• Your storage type does not support RDMs. For more information, see Comparing Types of Storage in the Configuration Guide for your version of VMware ESX.
  
• There are no available LUNs to be presented to an ESX/ESXi host. They may have already been committed to storing VMFS, or have already been mapped to other virtual machines as RDMs.
  
• vCenter Server has an older cache of known devices which can be used for RDMs, not including the intended LUN. Rescan your storage to pick up the changes. For more information, see Performing a rescan of the storage (1003988).
  
• You are using a SAS Direct Attached Storage (DAS) array that is being detected as Local Storage. For more information, see Creating Raw Device Mapping (RDM) is not supported for local storage (1017530).
  
• The option RdmFilter.HbaShared is selected in ESX/ESXi 4.1 or 5.x. To deselect this option, clickConfiguration > Software > Advanced Settings > RDM Filter, deselect the option, then click OK. For more information, see Configuring advanced options for ESX/ESXi (1038578).
  
• You are using an external shared SAS storage array like the Dell MD32xx. This requires that the checkboxRdmFilter.HbaShared is deselected in order to use a LUN as RDM. This is expected behavior because the RDM filter only applies to Fiber Channel, FCoE and iSCSI.

Source:-

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

Disabling or turning Off VMware FT (1008026)

Details

You might need to either disable or turn off the VMware Fault Tolerance (FT) feature. For example, if you are downgrading a license, VMware FT might not be supported by the downgraded license. In such a case, you must first disable or turn off VMware FT for all virtual machines on which VMware FT is currently enabled.

Disabling VMware FT preserves the secondary virtual machines, their configuration, and all history. Use this option if you might re-enable VMware FT in the future. Turning off VMware FT deletes all secondary virtual machines, their configuration, and all history. Use this option if you do not plan to re-enable VMware FT.

Solution

To disable VMware FT on a virtual machine:

• In the vSphere Client, right-click the virtual machine with Fault Tolerance enabled, click Fault Tolerance, and click Disable Fault Tolerance.

To turn off VMware FT on a virtual machine:

• In the vSphere Client, right-click the virtual machine with Fault Tolerance enabled, click Fault Tolerance, and click Turn Off Fault Tolerance.

Note: Disabling or turning off VMware FT can be performed whether the virtual machines are powered on or powered off.

Note: If you are downgrading a license and FT is no longer supported by this license, ensure that Fault Tolerance Logging is disabled on the VMkernel Port. For related information, see:

• Cannot license your ESX host or connect ESX host to vCenter Server after converting a vSphere license from Enterprise or Enterprise Plus to a lower edition (1017843)
• Enabling license downgrade by disabling features (1010433)

Source:-

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

Clone vs. Template

Most of the time frequently asked question is that what is the difference between Clone and Template. So this is the difference between Clone and Template

VM clones are best suited in test and development environments where you want to create, test and work; with exact copies of production servers without disturbing production servers by creating a clone of the production virtual machine.

Templates are best suited for production environments where you want the mass deployment of Virtual Machines along with the installed OS, basic software, and configured settings such as the security policy of your organization, as a base VM. Once a template is deployed, you can install software depending on the role of the server for example IIS or Database.

vCenter Single Sign-On installer reports the error: Error 29155.Identity source discovery error (2034374)

Symptoms

When installing vCenter Server 5.1, you experience these symptoms:

• During the installation, an attempt is made to automatically discover an Active Directory domain
• While discovering Identity Sources as part of the vCenter Single Sign-On install, you see the error:
  
  Error 29155.Identity source discovery error
  
• When you click OK in the error dialog, the vCenter Single Sign-On installation continues despite the message
• Subsequent component installations may fail as the machine is not joined to a domain

Cause

This issue occurs because automatic discovery of an Active Directory domain can sometimes fail, usually due to environmental reasons such as security restrictions.

Resolution

This is a known issue, and is currently being reviewed by VMware. This article will be updated as information becomes available. For related information see the Known issues section in the VMware vCenter Server 5.1.0a release notes.

To work around this issue when you are not able to upgrade, manually add an identity source.

To manually add an identity source:

1. Skip ahead in installation components and install the vSphere Web Client after the vCenter Single Sign-On installation completes.
2. Manually add a domain as an identity source using the admin@system-domain account. For more information, seeAdd a vCenter Single Sign-On Identity Source in the vSphere 5.1 Documentation Center.
3. Resume installing any components that failed to install previously.

Source:-

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

Vmware Certification Information

Link For Vmware Certifications:-
http://mylearn.vmware.com/portals/certification/

What is Co-Scheduling?

Proportional Share

ESX uses a proportional share algorithm to schedule virtual machine worlds to run on physical CPUs.  A world is more or less a process.  Thanks to all of the resource management capabilities that ESX provides, it is not always so easy to decide who gets to process first, and for how long.  Typically, if all things are equal, you would just create a list, and have every process execute in turn.  Well, reservations, limits, shares, add an added dimension to that process.  So, ESX factors in that information and creates something called an entitlement.  With that, you now have a world, and a world has an entitlement.  If a world is entitled to a resource, and has not yet consumed it, then it now has priority to be scheduled to run. As and when that world runs, its run time has to be accounted for, so as to keep track of the consumption of the entitlement.  That time is called charging.  In other words, a vm is entitled to resources, and is charged for consumption of those resources.  The vm in essence prepays for “talk time” with its entitlements.  As and when it talks, it is charged for that time, and its balance goes down.  If it hasn’t consumed all of its time, it gets priority when it wants to make a call.  The higher the talk time remaining, the greater its priority.

Simple enough, I suppose, but what happens when a vm has more than a single vCPU to worry about.  This is where co-scheduling comes into play.

Co-Scheduling

Simply put, if you create a virtual machine with more than 1 vCPU, ESX will make every attempt to schedule those worlds to run together.  That is co-scheduling in its simplest terms.  There are additional considerations that have to be made to keep the guest OS happy when you use multiple processors.  The processor access has to be symmetric, hence the Symmetric MultiProcessing in vSMP.  If you have a single vCPU making progress out of a two vCPU configuration, that difference in progress is called skew.  Now, I say progress, instead of simple runtime, because a vCPU can make progress when it uses CPU, or when it halts or idles.

When skew gets beyond a certain threshold, the guest OS will think one of its processors have died.  If you’re lucky, the OS will mark the processor bad, and keep chugging along.  If you’re not lucky, and most of us who have dealt with the physical server world know that when an OS loses a CPU you will not be lucky and the OS will crash and burn.  There’s a reason that most every admin knows the meaning of a BSOD/PSOD or a kernel panic.  How the skew is managed has changed over ESX scheduler iterations, from Strict, to Relaxed, to “even more Relaxed”?

Strict Co-Scheduling

Strict co-scheduling was employed with ESX 2.x.  Under strict co-scheduling, the skew is cumulative per each vCPU of an SMP virtual machine, meaning the skew grows when a vCPU does not make progress relative to any other vCPU in the same vm.  If the skew becomes greater than a set threshold, the entire virtual machine stops processing.  This vm will co-stop and will not be scheduled again, or co-start, until there are enough physical CPUs available to schedule all of the vCPUs simultaneously.  This is an attempt to shrink the skew, and if nothing else, to not allow the skew to grow any larger.  This also ends up causing CPU fragmentation, when a 2 vCPU vm can not run because only 1 pCPU is idle and available to process, causing a scheduling delay until a second physical CPU is ready to go.

This “co-stop penalty” is larger for larger SMP virtual machines, than for smaller, because a greater number of physical CPUs need to be ready to run.  So, a 2 vSMP virtual machine will be scheduled faster than a 4 vSMP virtual machine.  You can see how large this penalty is with esxtop.  The %CSTP counter under CPU represents the % of time the world spent ready to go, but co-descheduled or co-stopped.

Relaxed Co-Scheduling

Then along comes relaxed co-scheduling with ESX 3.x and made things quite a bit better.  Whereas previously, all vCPUs had to be scheduled together, under relaxed co-scheduling, once a skew threshold is reached, the virtual machine stops, but now only has to have enough pCPUs available to allow the vCPUs with high skew to co-start together.  So, in a 4 vCPU virtual machine, if only 2 vCPUs had enough skew, only those are required to co-start together, so only 2 pCPUs need to be available for those vCPU to make progress.  ESX will still make every attempt to co-start all of the vCPUs together, but it is no longer required to do so.  It will take what it can get.

ESX4 Even More Relaxed Co-Scheduling

ESX4 went even further and changed the skew detection to further reduce time spent de-scheduled or in co-stop.  Instead of a cumulative skew per each vCPU, skew is now measured for each vCPU as the difference in progress between each vCPU and the slowest vCPU.  The virtual machine in this case does not have to co-stop all vCPU, and the skewed vCPU co-started together.  Instead, if  any vCPU individually exceeds a threshold, that vCPU will alone be stopped until the other slow vCPUs have caught up.   Now the vCPU can be started by itself.  Again, ESX will attempt to co-schedule all vCPUs together, but it can now individually stop and start vCPUs as needed.

This gives ESX much more opportunities to schedule small and large SMP virtual machines than it could previously, and those virtual machines now perform much better than they had before.

Ultimately, remember that there is a penalty to using vSMP.  Not every application benefits from being given an additional processor to run on and it takes overhead on the part of ESX to track and manage that additional processor.  Balance that cost with the benefit to your application, and use vSMP sparingly.

NAA Id's

After searching around and not finding anything that covers the entire string, I figured I’d throw in what information I have.  I like to label my datastores with my source information, which makes it easy to search and isolate when SAN work has to be performed.  The labels make it easy, but I’m relying on information gathered to create these labels.  So, this is a way, if nothing else, to validate that the information is being applied to the correct identifier.

The identifier comes in the form of naa.aaaaaaaabbbbbbbbbbbbccdddddddddd .  I’ve been able to find a somewhat reliable means to describe a, b, and d, but for some odd reason, c does not quite fit in.  But, for what it’s worth, I’ve been able to gather vendor, device, and lun.

The breakdown is as follows:

• aaaaaaaa is an 8 digit vendor identifier, and I’ve listed the vendors we use below, as well as others I’ve been able to find online:
• 60060480 <— EMC
• 60060e80 <— HDS
• 60a98000 <— NetApp
• 60060160 <— DGC (Clarrion?)
• 6090a038 <— EQL
• bbbbbbbbbbbb is a 12 digit serial # of the device providing the storage.  This may differ from device to device, but matches up perfectly to the id’s from our Symm.  Our mileage may vary, but it’s held up so far.
• cc is a 2 digit code for something.  No idea as of yet, and I’ve managed to stump some other smart folks.  If anyone has any ideas on this one, please share.  It’s very frustrating to puzzle out 30 / 32 digits, and leave 2 digits in the wind.
• dddddddddd is a 10 digit LUN identifier.  This differed based on the device on how the device ID is actually represented.
• HDS – was the most straightforward.  It represented in the naa id, the actual device ID being used on the array side.
• EMC – was very confusing.  You will have to take the 10 digits in pairs, that will give you the ASCII code in hex, for the pair, which after being concatenated give  you the device id.  Very straightforward, I know.  Here’s an example:
• 60060480bbbbbbbbbbbb533031464446
• 60060480 makes this EMC
• bbbbbbbbbbbb serial number which I’ll keep to myself.
• 53 which will drive me crazy
• 3031464446 –> which will break down to 30  31  46  44  46 –> which gives us a device id of 01FDF
• 30 –> converted to decimal from hex= 48 –> which in ASCII = 0
• 31 –> converted to decimal from hex= 49 –> which in ASCII = 1
• 46 –> converted to decimal from hex= 70 –> which in ASCII = F
• 44 –> converted to decimal from hex= 68 –> which in ASCII = D
• 46 –> converted to decimal from hex= 70 –> which in ASCII = F