Test and Repair Rule Compliance

If you change a rule set: 
- Unprovisioned hosts boot automatically according to the new rules. 

-For all other hosts, Auto Deploy applies new rules only when you test a host’s rule compliance and perform remediation.

When you add a rule to the Auto Deploy rule set or make changes to one or more rules, hosts are not updated automatically. Auto Deploy applies the new rules only when you test their rule compliance and perform remediation.

This task assumes that your infrastructure includes one or more ESXi hosts provisioned with Auto Deploy, and that the host on which you installed VMware PowerCLI can access those ESXi hosts.

Prerequisites

■	Install VMware PowerCLI and all prerequisite software.
■	If you encounter problems running PowerCLI cmdlets, consider changing the execution policy. See Using Auto Deploy Cmdlets.

Procedure

1	Use PowerCLI to check which Auto Deploy rules are currently available. Get-DeployRule The system returns the rules and the associated items and patterns.
2	Make a change to one of the available rules, for example, you might change the image profile and the name of the rule. Copy-DeployRule -DeployRule testrule -ReplaceItem MyNewProfile You cannot edit a rule already added to a rule set. Instead, you copy the rule and replace the item or pattern you want to change.
3	Verify that the host that you want to test rule set compliance for is accessible. Get-VMHost -Name MyEsxi42
4	Run the cmdlet that tests rule set compliance for the host, and bind the return value to a variable for later use. $tr = Test-DeployRuleSetCompliance MyEsxi42
5	Examine the differences between what is in the rule set and what the host is currently using. $tr.itemlist The system returns a table of current and expected items. CurrentItem ExpectedItem ----------- ------------ My Profile 25 MyProfileUpdate
6	Remediate the host to use the revised rule set the next time you boot the host. Repair-DeployRuleSetCompliance $tr

What to do next

If the rule you changed specified the inventory location, the change takes effect when you repair compliance. For all other changes, boot your host to have Auto Deploy apply the new rule and to achieve compliance between the rule set and the host.

Source

FAQ for VMware vSphere Storage Appliance (VSA) 1.0.x

Purpose

This article provides answers to frequently asked questions about the VMware vSphere Storage Appliance (VSA).

Resolution

Q. The documentation explains how to replace a VSA member, but does not explain how to add a new member (for instance, if you have two and want to add a third). Is this possible?

A. In VSA 1.0, you can create a 2 or 3 node cluster, but once created you cannot add or delete a node. For more information, seeUnable to add or remove VMware Virtual Storage Appliance nodes/members after installation (2001340).

Q. Can VSA be installed on non-English vCenter Servers?

A. Yes. VSA 1.0 supports i18N level 0, which means that the English version of the VSA can be installed on non-English Operating Systems.

Q. The documentation states that all hard disks must be only SATA or SAS (a combination of SATA+SAS is not supported) and must have the same capacity. Is this enforced? If so, is there any workaround?

A. This is not strictly enforced. The software finds the ESXi host with the least amount of local storage available, and all hosts use that amount of storage. For example, if there are three hosts providing local storage of 3 TB, 2 TB, and 2.5 TB to the VSA Cluster, the VSA Cluster only consumes 2 TB from each node. On the other two nodes, the additional storage is unavailable for use.

For more information, see VSA Cluster Requirements in the VSA documentation.

Q. Can the ESXi hosts running VSA have more than 4 NICs?

A. Yes, but they will not be used for VSA traffic by default.

For more information, see VSA Cluster Network Architecture in the VSA documentation.

Q. Is there are any production disadvantages to crossover cable connection between VSA backend interfaces?

A. This is an untested configuration and therefore not supported. Though it may work.

Q. Can you configure VSA to do NIC teaming with more than two physical NICs (whether you do from VSA or from vCenter Server/ESX)?

A. Yes, from the vSphere Client on each host.

The VSA installer does not utilize more than 4 NIC ports configured as active/standby uplinks across the two VSA virtual switches. However, the administrator can manually configure additional active uplinks for either of the vSwitches or their component port groups via vCenter Server.

Note: This can be used to add redundancy, but not to increase network bandwidth between any two ESXi hosts. None of the vSphere NIC teaming load-sharing policies load balance/share network IO across multiple active teamed uplinks for the same TCP connection. In a three-node VSA cluster, the IP Hash load-balancing policy can be used to distribute network traffic among multiple uplinks, such that each pair of ESXi hosts communicates over a different channel.

For more information, see VSA Cluster Network Architecture in the VSA documentation.

Q. Where does the VSA Cluster Service run if you have 2 ESXi nodes? How about 3 nodes?

A. The VSA Cluster Service is always installed on the vCenter Server machine. In a two-node VSA cluster, the service participates in the cluster. In a three-node cluster, the VSA Cluster Service is not configured and does not participate in the cluster.

For more information, see VSA Cluster Architecture in the VSA documentation.

Q. How do you restart the VMware VSA Cluster Service?

A. The VMware VSA Cluster Service appears as a normal Windows service. Connect to the server where the VSA Cluster Service is installed, open the Windows Services list (services.msc) and locate the VMware VSA Cluster Service. To restart, right-click and choose Restart.

Q. In a 2-node cluster, if the VSA Manager Service stops, does the VSA cluster remain online?

A. Yes. The VSA cluster is a quorum-based system. Each VSA has a vote, and the VSA Cluster service provides the third vote. As long as there are 2 votes, the cluster is online.

• If both VSAs are online and the VSA Cluster is down, the cluster is online.
• If one VSA is online and the VSA Cluster service is on line, the cluster is online.
• If one VSA is offline and the VSA Cluster service is offline, the cluster is down.

For more information, see How a VSA Cluster Handles Failure in the VSA documentation.

Q. Is it supported to have vCenter Server installed in a virtual machine that is stored on the VSA?

A. No. If there are only 2 VSA nodes and one of them goes down and it happens to be also running the vCenter Server virtual machine, two votes in the VSA quorum would be lost, and the cluster would be marked offline. For more information, seeRunning vCenter Server in a virtual machine within a VSA cluster is not supported (2004834).

Q. Where are logs for the VSA stored?

A. Within the VSA nodes and on the VSA Manager server. For more information, see Location of VMware Virtual Storage Appliance log files (2003547).

Q. Can logs be collected from vCenter Server?

A. Yes. For more information, see Collecting diagnostic information from a VMware Virtual Storage Appliance cluster (2003549).

Q. I am experiencing an issue performing a manual VSA installation. Where are the logs for the VSA installer?

A. The installer automatically rolls back if any failure happens but leaves installer logs at TEMP%\vminst.log or%TEMP%\vim-vsa-msi.log. For more information, see Location of VMware Virtual Storage Appliance log files (2003547).

Q. Imagine you have a ESXi host running VSA that is experiencing an issue. Can you use the Replace VSA option to reinstall VSA on that node? If not, is there any workaround to avoid having to use an additional host?

A. Yes. The old VSA node first must be powered off before it can be replaced. The IP address of the replacement node must be different the original node, otherwise the check fails. For more information, see Replacing a VMware Virtual Storage Appliance cluster member with itself (2004837).

Q. After VSA Manager installation, the plug-in does not appear in vCenter Server. Is it possible to reinstall the VSA Manager Plug-in without reinstalling VSA Manager itself?

A. Yes. Ensure that vCenter Server's tomcat service is running, and enable the VSA Manager Plug-in through vCenter Server's Plug-in Manager. For more information, see Enable the VSA Manager Plug-In in the VSA documentation.

Q. Can I use VLAN only for the back-end network?

A. Yes, leave VLAN 0 (zero) for the front-end network and the desired VLAN for back-end network. VLAN 0 equals no VLAN.

Q. Is the use of VLANs enforced? If so, is there any tweak available to make VSA work without VLANs?

A. VLANs are recommended but not required. For more information, see Reconfigure the VSA Cluster Network and Network Switch Requirements for a VSA Cluster in the VSA documentation.

Q. Is there any VSA configuration maximum for sizes of local storage per host/per LUN?

A. Yes. There is a configuration maximum for the amount of local storage per ESX host that a VSA virtual machine uses. The limit is 32 TB of storage, spread evenly across 8 VMFS virtual disks used as data disks by a VSA virtual machine. This equals 64 TB of raw storage for an ESX host exporting RAID10 storage, and about 42.7 TB for an ESX host exporting RAID5 storage configured as two RAID sets of 4 drives. For more information, see VSA Cluster Capacity in the VSA documentation.

Notes:

• Approximately 20 GB of storage remain unallocated by VSA on the ESXi host's local datastores.
• The ESXi host's local storage hardware may impose additional limits, such as 2 TB storage devices.

Q. How do I know if my hardware supports VSA?

A. For a list of all hardware qualified to run VSA, see the VMware Compatibility Guide. Ensure that vSphere Storage Appliance is selected under the Features criteria.

Q. Is VMX Swapping enabled or disabled by default?

A. VMX swapping is enabled by default. You can prevent virtual machines from VMX swapping to the VSA datastores by disabling VMX swapping on each virtual machine that runs in the VSA cluster. For more information, see Memory Overcommitment Not Supported in a VSA Cluster in the VSA documentation.

Q. Are the NFS datastores mounted on all the ESXi hosts in the target Datacenter or the target Cluster?

A. The NFS datastores are mounted to all ESXi hosts at the Datacenter level. However, vMotion does not work unless the VSA-VMotion port group is added to every cluster. For more information, see Reconfigure the VSA Cluster Network in the VSAdocumentation.

Q. What is the username and password for console access to the VSA nodes?

A. The username is svaadmin. The default password is svapass. For more information, see Change the VSA Cluster Password in the VSA documentation.

Q. Where is the VSA cluster password stored?

A. The user/password are stored as an actual Linux user/password on each VSA. The password is encrypted by Linux. The VSA cluster takes care of coordinating the update to each VSA.

Q. If vCenter Server or VSA Manager must be reinstalled to recover a VSA cluster, which password do I use: the default VSA password or the new one?

A. When reinstalling vCenter Server or the VSA Manager to recover a cluster, use the current password, not the original/default password.

Q. What is the minimum amount of local disks on each ESXi host?

A. VSA 1.0 supports a configuration of 4, 6, or 8 local disks per host. For more information, see the Release Notes.

Q. My ESXi has more than one datastore. Can I specify the datastore that VSA should use?

A. VSA 1.0 expects only a single datastore on the ESXi server, and you cannot select a different datastore.

It could be possible that you make other datastores not visible during VSA installation, which should work but later on if you need to use some procedures like 'replacing a node' the availability of multiple datastores could cause problems. Therefore only one datastore in each ESXi host in the VSA Cluster is the only supported configuration.

Q. Does the vSphere Storage Appliance support vSphere APIs for Array Integration (VAAI)?

A. VSA supports the VAAI NAS space reservation interface. This mechanism is used whenever the creation of a non-Thin virtual disk on a NAS-VAAI-capable datastore is requested, such as when creating, cloning, or migrating a virtual machine. VSA does not support the VAAI NAS snapshot offloading interface.

Q. Can I protect virtual machines that reside on vSphere Storage Appliance (VSA) datastores with Site Recovery Manager (SRM) 5.0?

A. Yes, virtual machines that reside on the vSphere Storage Appliance (VSA) can be protected by SRM 5.0 using vSphere Replication (VR). VSA does not require a Storage Replication Adapter (SRA) to work with SRM 5.0. This information is provided in the SRM Release Notes as well.

For more information, see our blog post vSphere Storage Appliance 1.0 & Site Recovery Manager (SRM) 5.0 Interoperability.

Q. Can I use VSA with vCenter in Linked mode?

A. Yes, Linked-Mode vCenter server feature can be used for managing a remote VSA. For more information, see our blog postUsing the Linked-Mode vCenter feature for managing a remote VSA.

Q. Can I change the IPs and VLANs of a VSA cluster after it has been installed?

A. Yes, use the Reconfigure VSA Cluster Network option from the VSA Manager tab.

Q. Can I mount the VSA storage as NFS shares to entities outside the VSA Cluster?

• Yes, it is supported for other ESX hosts in the same vCenter datacenter as the ESX hosts that are hosting the VSA cluster. For more information, For more information, see Mounting VMware vSphere Storage Appliance NFS datastores on ESXi hosts manually (2004833).
• It is not supported to mount the VSA NFS shares onto a virtual machine.

Q. In the event of a planned power outage to our physical environment, what is the procedure for shutting down the ESXi hosts that contain VSA?

A. To shut down the ESXi hosts that contain VSA:

1. Shut down all virtual machines within the datacenter on the ESXi hosts.
   
   Note: This is a limitation of VSA 1.0 only.
   
2. Shut down Production virtual machines on the ESXi hosts.
3. Put the VSA Cluster into maintenance mode.
4. Power off VSA Appliances on the ESXi hosts.
5. Power down the ESXi hosts

For more information on the VSA shutdown procedure, see Performing a controlled power down of a VMware vSphere Storage Appliance cluster (2019135).

Q. Is ESXi 5.0 Embedded (non-installable version) or stateless supported with VSA 1.0?

A. ESXi Embedded is burned on a USB or Flash drive on the server, typically in environments without a local disk. VSA 1.0 is supported only on ESXi Installable and not on embedded or stateless ESXi.

Q: If I remove VSA Manager, does the VSA cluster service gets deleted from vCenter Server?

A: Yes, VSA Manager and the VSA cluster service are removed from vCenter Server. It there is an existing VSA Cluster (VSA appliances running on hosts), it is left as it is.

Q: If I have a healthy VSA Cluster and I remove and reinstall VSA Manager on the same vCenter Server, can I recover management over the existing VSA Cluster?

A: Yes. In fact, you need not do the recover process. When you open the VSA tab, you see the VSA cluster as it was before you removed the VSA Manager. Note that reinstalling VSA Manager does not have any effect on an existing healthy/unhealthy VSA Cluster.

Q: Can I install a VSA Cluster in a non-supported hardware (non-supported ESXi hosts)?

A: Yes, to some extent. The wizard displays a warning about the unsupported hardware, however it does not stop you from continuing. If the hosts do not support EVC, the installation fails later when you attempt to create the cluster of ESXi hosts in vCenter Server.

Q: My hardware is on the HCL, but the VSA 1.0 software says that it is unsupported.

A: The software contains a list of hardware that were supported at the time VSA 1.0 was released. If more supported machines are added after that date, the software is unaware of it and says that they are unsupported. The HCL contains an accurate list of supported hardware.

Q: Can I configure jumbo frames on the back-end network?

A: No. The VSA does not support jumbo or super jumbo Ethernet frame sizes for networking of ESX hosts in a VSA cluster. The CPU resource savings that might be expected from transmitting jumbo frames is already realized with physical and virtual interrupt coalescence for physical (ixgbe) and virtual (vmxnet3) NICs and TCP Large Receive Offload (LRO) configured on the physical NICs. While there is network bandwidth savings that could be realized by submitting fewer network frames, this benefit is considered to be minor.

Q: Does the VSA support Virtual Machines running in an FT (Fault Tolerant) configuration?

A. Yes. FT virtual machines can run on VSA datastores, however the FT virtual machine should not run on an ESXi server that is running a VSA server in the VSA cluster hosting same datastore. Customers should be aware that during VSA fail-over and recovery, I/O requests from an FT virtual machine (or any virtual machine) using a VSA datastore may be temporary suspended.

Q: Once a VSA node that has failed comes back up, the data is being replicated back to the node. Regarding the data being replicated, is it just the changes in the volume since the node went down, or would it be creating the volume completely?

A: The VSA’s data replication technology includes change tracking at the granularity of 64 MB chunks. This allows us to synchronize only the chunks that were modified when the volume is degraded. Therefore the answer to your question is, “we don’t recreate the volume.” But the amount of data synchronized could be greater than the amount which was actually modified.

Q: When is a datastore placed in the degraded state?

A: A datastore is placed in the DEGRADED state whenever a replica of the volume is unavailable, or when the 2 replicas are not in sync. This happens whenever a VSA member goes offline or the communication between the 2 nodes is broken (no network).

Q: How is it possible for a VSA node to enter maintenance when the user hasn't specifically requested it?

A: The VSA will automatically enter maintenance mode if it detects that it has rebooted 3 times within 15 minutes. This does not include reboots that were user-requested from the Guest OS (though a VSA VM reset done outside of the VSAManager UI would still not count as user-requested). The reason for this logic is to stop instances of a cyclic reboot of a VSA. In other words, a VSA that has run into a situation where a problem is causing it to continuously reboot itself. In an attempt to preserve log information on the initial cause of the reboot cycle, we try to catch it by automatically placing the VSA into maintenance mode. As a result, it does not rejoin the storage cluster and therefore any affected datastore(s) would remain in a DEGRADED state until that VSA is either:

• manually taken out of maintenance mode and an attempt to reintegrate with the cluster is attempted (for more information, see VSA appliance cannot exit maintenance mode (2018009)); or
• replaced with a new VSA/ESXi host to correct for the failing VSA/ESXi host.

Q: I configured a virtual machine running a SQL server on the VSA datastore. The HA boot sequence is configured to start VSA first and then the virtual machine. There was a power outage and on start up, both servers start at the same time. VSA starts but only offers its datastore service after it has finished booting completely, and the ESXi host finished booting up before VSA. The ESXi host then tries to power on the virtual machine but the datastore is not yet available. What happens in this situation? Will ESXi eventually detect that the VSA datastore is available and start the virtual machine? Will the virtual machine become non-responsive until we rescan the datastore?

A: HA retries the virtual machine power on for up to an hour with an exponential back-off (with the first retry attempted after one minute). A total of seven attempts will be made within 64 minutes, and if the virtual machine cannot be powered on after that, HA abandons the attempts and a permanent error is posted.

Source:-

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

When does VMware Data Recovery use network based copy instead of SCSI Hot-Add?

Purpose

This article identifies the conditions in which network based copy is used instead of SCSI hot-add when performing a backup using VDR.

Resolution

VMware Data Recovery (VDR) attempts to use SCSI hot-add first. If that fails, VDR automatically falls back to a network based copy. There are several conditions under which SCSI hot-add is known to fail:

• The virtual machine being backed up has IDE disks. SCSI hot-add does not work with IDE disks.
• The datastore hosting one or more of the virtual machine's disks is not accessible to the ESXi/ESX host running the VDR Appliance.
• The VMware Data Recovery Appliance runs out of free Virtual SCSI slots. The appliance supports up to 4 SCSI controllers. Each controller can support 15 SCSI devices. This allows for 60 SCSI disks being attached. The appliance uses one of those slots for its boot disk and one for each VMDK-based Deduplication Store. You can add SCSI controllers as needed.
• The VMware Data Recovery Appliance is configured with Virtual SCSI Controllers other than "LSI Logic Parallel". Hot adding virtual disks to the appliance is supported only with the "LSI Logic Parallel" virtual SCSI controller.
• The configuration file /var/vmware/datarecovery/datarecovery.ini contains the option DisableHotaddCopy=1. For more information, see VMware Data Recovery: Enabling verbose logging and datarecovery.ini options (1013175).
• There is a limitation with mismatched block size. Hot-add cannot be used if the VMFS block size of the datastore containing the virtual machine folder for the target virtual machine does not match the VMFS block size of the datastore containing the proxy virtual machine. For example, if you back up a virtual disk on a datastore with 1 MB blocks, the proxy must also be on a datastore with 1 MB blocks. For related information, see Virtual Disk Transport Methods.

Note: There was an issue that unintentionally restricted backups for Essentials Plus. This issue is resolved with third-party backup products using VDDK 5.0 Update 1. This is also a known issue with vDR, and is being reviewed by VMware. This article will be updated as information becomes available.

Source:

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

Cannot change an ESX host's vpxuser account back to its default settings

Resolution

The vpxuser account is created by VirtualCenter when an ESX host is added. Do not manipulate this account.

 

You must delete and recreate the vpxuser account to reset it back to its default settings.

 

To delete and recreate the account:

1. Right-click the ESX host in VMware Infrastructure Client that is connected to VirtualCenter and chooseDisconnect if it does not already show as not responding or disconnected already.
   
   Note: Do not remove the ESX host.
   
2. Connect to the ESX host console as root directly, via a remote KVM, or using an SSH client. For more information, see Connecting to an ESX host using a SSH client (1019852).
3. Run the command:
   userdel vpxuser
   
4. Right-click the ESX host in VMware Infrastructure Client that is connected to VirtualCenter and choose Connect.
   
   Note: Ignore any login failure errors that display in the Tasks.
   
5. Enter the root user and password and follow the prompts to connect the ESX host.
   
   VirtualCenter recreates the vpxuser account with the default settings.

Source:-

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

Determining if a High Availability Virtual Machine Monitoring event caused a virtual machine to reboot

Symptoms

• A virtual machine running on an ESX/ESXi host appears to have been rebooted unexpectedly
• The ESX/ESXi host where the virtual machine is registered is a part of an VMware High Availability (HA) cluster in vCenter Server and Virtual Machine Monitoring is enabled on the HA cluster.

Purpose

It can be difficult to determine the cause of an unexpected virtual machine reboot. This article provides information about the logs and events to look for to determine if the reboot was caused by HA Virtual Machine Monitoring.
Provides a workaround for disabling Virtual Machine monitoring.

Resolution

To look for events related to the virtual machine in vCenter Server:

1. Select the virtual machine in vCenter Server.
2. Click the Tasks & Events tab.
3. Click the Events button.
4. Enter the word reset in the search field.
5. If HA Virtual Machine Monitoring was responsible for resetting the virtual machine, an Event similar to this displays:
   
   This virtual machine reset by HA. Reason: VMware Tools heartbeart failure. A screenshot is saved at /vmfs//volumes/4c4850e4-0dcce710-28d9-00215-a5d36b8/wdcsmdc2/wdcsmdc2-screenshot-0.png
   
   Example:
   
   
   
   Note: The reason in the Description field may differ slightly, but it always states that the virtual machine was reset by HA if Virtual Machine Monitoring is involved.

On the ESX/ESXi host, two logs can help identify Virtual Machine Monitoring as the source of the virtual machine reboot. If Virtual Machine Monitoring is the cause:

• The /var/log/vmware/hostd.log file contains entries similar to:
  
  [2010-09-14 16:13:09.094 F5760B90 verbose 'vm:/vmfs/volumes/4c4850e4-0dcce710-28d9-00215a5d36b8/wdcsmdc2/wdcsmdc2.vmx'] Updating current heartbeatStatus: red
[2010-09-14 16:14:46.969 F5B73B90 verbose 'vm:/vmfs/volumes/4c4850e4-0dcce710-28d9-00215a5d36b8/wdcsmdc2/wdcsmdc2.vmx' opID=task-internal-977-4429b01] Reset request received
• The vmware.log for the affected virtual machine (/vmfs/volumes/<datastore>/<VM directory>/vmware.log), contains entries similar to:
  
  Sep 14 16:14:47.004: vmx| Vix: [104333 vmxCommands.c:392]: VMAutomation_Reset
Sep 14 16:14:47.016: vmx| Vix: [104333 vmxCommands.c:457]: VMAutomation_Reset. Trying hard reset
Sep 14 16:14:47.017: vmx|
Sep 14 16:14:47.017: vmx|
Sep 14 16:14:47.017: vmx| VMXRequestReset
Sep 14 16:14:47.018: vmx| Stopping VCPU threads...

Note: Knowing the time of the unexpected reboot helps in searching the log files, as you can look for the time stamp.

If any of the relevant log entries or the vCenter Server event are present, HA Virtual Machine Monitoring restarted the virtual machine as it was not receiving virtual machine heartbeats (via VMware Tools) and there was no I/O on the virtual machine.

Examine the logs within the guest operating system to help determine the cause of the event. If multiple virtual machines are affected, review the vmkernel, messages, and hostd logs on the ESX host where the virtual machines are registered to look for a system wide problem.

To workaround this issue, disable Virtual Machine Monitoring:

• Log in to the vCenter Server using the vSphere Client.
• Right-click on VMware HA Cluster and choose Edit Settings
• In the Cluster Settings dialog box, Select VM Monitoring
• VM Monitoring Status: VM Monitoring drop down box, select Disabled
• Click OK

Note: This feature can also be disabled on the VMware HA page of the New Cluster Wizard by deselecting Enable Host Monitoring.

Source:-

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

Comparing the behavior of vCenter Single Sign On with earlier versions of vCenter Server

Purpose

This article explains the differences in the behaviour of Single Sign on in vCenter Server 5.1 and earlier versions.

Note: This is a not a comprehensive guide. For more information, see the vSphere 5.1 documentation. The documentation contains definitive information. If there is a discrepancy between the documentation and this article, assume that the documentation is correct.

Resolution

vSphere 5.1 introduces a new independent Single Sign On service as part of the vCenter Management Infrastructure.

Authentication by vCenter Single Sign On makes the VMware cloud infrastructure platform more secure by allowing the various vSphere software components to communicate with each other through a secure token exchange mechanism, instead of requiring each component to authenticate a user separately with a directory service like Active Directory.

This impacts the way the management software is installed, deployed, configured, and used.

Behavior during the installation or upgrade

If you are performing a fresh installation of vCenter Server 5.1 or upgrading from an earlier version, ensure that you are aware of these changes:

Behavior	vCenter Server 5.0 or earlier	vCenter Server 5.1
Installer	Setup.exe	Auto launcher that guides through the installation
Installation steps	Single installer installs vCenter Server and silently installs the Inventory service.	Three separate installers are available on the auto launcher. These components need to be installed the order: Single Sign On (SSO) Inventory Service (IS) vCenter Server (VC) Each of these can be installed in a different host or virtual machine. SSO can be installed in multiple modes: Standalone Cluster (single site high availability) Multisite (High availability) For more information, see Installing vCenter Single Sign On in a multisite deployment (2034074).
Upgrade from vCenter Server 4.x or 5.0	The local operating system user or Active Directory users registered with vCenter Server can continue to work with the new vCenter Server.	The upgrade process installs SSO first and then upgrades vCenter Server. AD use case In case of AD, if SSO is running in a virtual machine or host that is in the same domain as AD, SSO auto discovers the AD domain and joins it automatically during the SSO install process. Otherwise, the user must log in to the vSphere Web Client and add the AD domain to SSO. Local OS users If you are installing SSO and vCenter Server in the same host or virtual machine, the existing local operating system users are picked by SSO. Upon upgrade, one can log in to vCenter Server with the registered local operating system user ID. If SSO and vCenter Server are installed in different hosts or virtual machines, the former local operating system users (used for logging in to vCenter Server) are not be available to SSO. Therefore, new local users must be created in the host or virtual machine where SSO is being installed. In vCenter Server 5.1, local operating system users refer to the local users in the SSO machine.

Notes:

• For small vSphere deployments, vCenter Server 5.1 provides a vCenter Server Simple Install option that installs vCenter Single Sign On, Inventory Service, and vCenter Server on the same host or virtual machine.
• Alternatively, to customize the location and setup of each component, you can install the components separately by selecting the individual installation options in this order: vCenter Single Sign On, Inventory Service, and vCenter Server. Each component can be installed in a different host or virtual machine.
• For the first installation of vCenter Server with vCenter Single Sign On, you must install all three components, Single Sign On Server, Inventory Service, and vCenter Server, in the vSphere environment. In subsequent installations of vCenter Server in your environment, you do not need to install Single Sign On. One Single Sign On server can serve your entire vSphere environment.
• After you install vCenter Single Sign On once, you can connect all new vCenter Server instances to the same authentication server. However, you must install a Inventory Service instance for each vCenter Server instance.
• In vCenter Server 5.0 or earlier upgrades, both the local operating system users and Active Directory users that are registered with vCenter Server before the upgrade continue to work with the upgraded vCenter Server. This behavior changes in vCenter Server 5.1.
• In vCenter Server 5.1, if vCenter Single Sign On is running on a virtual machine or physical machine that is joined to an Active Directory domain, Single Sign On automatically discovers the existing Active Directory domain and adds it as an identity source during the Single Sign On installation process. If Single Sign On is not running on a virtual machine or physical machine that is in the same domain as Active Directory, you must use the vSphere Web Client to log in to vCenter Server and add the Active Directory domain to Single Sign On.
• If you install vCenter Single Sign On and vCenter Server on the same physical machine or virtual machine, Single Sign On recognizes existing local operating system users. After the upgrade, you can log in to vCenter Server with a registered local operating system user ID.
• If you install vCenter Single Sign On and vCenter Server on different hosts or virtual machines, the former local operating system users who managed login access to vCenter Server are not available to Single Sign On.
• When you install vCenter Single Sign On in multisite mode or clustered high availability mode, all pre-upgrade permissions for local operating system users are lost. In vCenter Server 5.1, the term local operating system users refers to those local users in the Single Sign On host machine instead of the vCenter Server host machine or virtual machine.
• After the upgrade, if no super administrator remains (the administrative user or group for the root folder), you must provide a valid user or group to be used as super administrator during installation. This situation can occur due to changes in user stores from pre-5.1 to 5.1 versions of vSphere.

For more information on installing vCenter Server Sign On, see the vSphere Installation and Setup guide.

Behavior after upgrading or installing vCenter Server and its services

Behavior	vCenter Server 5.0 or earlier	vCenter Server 5.1
Adding an AD domain	vCenter Server automatically adds those AD domains to which the host or virtual machine running vCenter Server is a part of.	SSO automatically discovers those AD domains to which the host or virtual machine running SSO is a part of. It adds those auto discovered AD domains to SSO.
Adding multiple AD domains	vCenter Server can also be configured for a different AD domain. However, at a given time only one AD domain can be configured with vCenter Server.	Using SSO, multiple AD domains can be added simultaneously.
Adding OpenLDAP	This was NOT possible in vCenter Server	SSO can add multiple OpenLDAP domains. vCenter Server can be configured for use by users from these OpenLDAP repositories. You can also do without AD if you choose to.

Notes:

• vCenter Server 5.0 or earlier versions add Active Directory domains that the vCenter Server host or virtual machine is part of. In vCenter Server 5.1, vCenter Single Sign On discovers those Active Directory domains that the vCenter Single Sign On host or virtual machine is part of.
• vCenter Single Sign On adds those discovered Active Directory domains. Unlike earlier vCenter Server versions, which permit only one Active Directory domain at a time to be configured for vCenter Server, in vCenter Server 5.1 with Single Sign On, you can add multiple Active Directory domains.
• vCenter Single Sign On can also add multiple OpenLDAP domains, and you can configure vCenter Server to be available to users who are registered with these OpenLDAP repositories, enabling you to manage vCenter Server access without Active Directory.

For more information on adding domains to vCenter Server 5.1, see the vSphere Security Guide.

Behavior or the user repository

Behavior	vCenter Server 5.0 or earlier	vCenter Server 5.1
User Repository	Active Directory (AD) Local OS users	AD OpenLDAP Local OS Users System Users

Notes:

• vCenter Server 5.0 and earlier versions support Active Directory and local operating system users as user repositories. vCenter Server 5.1 supports these types of user repositories as identity sources:
  
  
  • Active Directory
  • OpenLDAP
  • Local operating system
    
    Local operating system users are local to the operating system where the Single Sign On server is running, such as Windows. Only one local operating system identity source is allowed. The local operating system identity source exists only in basic Single Sign On server deployment.
    
  • System
    
    A fourth type of user repository is Single Sign On system users (System-Domain). Exactly one system identity source is always associated with an installation of Single Sign On. These users are contained in a database that is internal to the Single Sign On server. System users are not the same as local operating system users.
    
• You can attach multiple identity sources from each type to a Single Sign On server.

For information about configuring identity store support, see the vSphere Installation and Setup and vSphere Security Guides.

Behavior when authenticating to the vCenter Server environment

Behavior	vCenter Server 5.0 or earlier	vCenter Server 5.1
Authenticating to SSO Service	This did not exist.	Because the vCenter Server service now has an independent SSO service, users must be created to manage this service. These users may not be the same as the users administering vCenter Server. The default SSO administrator user id isadmin@System-Domain. SSO admin users can be created using the SSO Users and Groups navigation link. There are three permissions that can be associated with these users: Basic Regular Administrator
Authenticating to vCenter Server	Users connect to vCenter Server and vCenter Server authenticates the user by validating the user against an AD domain or local operating system.	Users do not authenticate to vCenter Server any more.

Notes:

• In vCenter Server 5.0 and earlier versions, when users connect to vCenter Server, they were authenticated when vCenter Server validated their credentials against an Active Directory domain or the list of local operating system users. In vCenter Server 5.1, users authenticate through vCenter Single Sign On.
• The default Single Sign On administrator is admin@System-Domain with the password you specified at installation. You use these credentials to log in to the Single Sign On administration tool in the vSphere Web Client. You can then assign Single Sign On administrator privileges to users who are allowed to manage the Single Sign On server. These users might be different from the users that administer vCenter Server.
• In the vCenter Server Appliance, local operating system administrators, such as root, also have vCenter Single Sign On administrator privileges.
• Logging in to the vSphere Web Client with Windows session credentials is supported only for Active Directory users of the domain to which the Single Sign On system belongs.
• ESXi 5.1 is not integrated with vCenter Single Sign On and you cannot create ESXi users with the vSphere Web Client. You must create and manage ESXi users with the vSphere Client. vCenter Server is not aware of users that are local to ESXi. In addition, ESXi is not aware of vCenter Server users. However, you can configure Single Sign On to use an Active Directory domain as an identity source, and configure ESXi to point to the same Active Directory domain to obtain user and group information. This action allows the same set of users to be available to the host and to vCenter Server.

For more information on using vCenter Single Sign On to Manage Users and Groups, see the vSphere Security guide.

Behavior when using the vSphere GUI

Behavior	vCenter Server 5.0 and prior	vCenter Server 5.1
vSphere Client	User logs in to each vCenter Server separately. All linked vCenter Server instances are visible in the left pane. vCenter Servers that are not linked are not visible unless the user connects to it explicitly.	Same behavior. None of the new capabilities of the vSphere 5.1 Web client is available on the vSphere Client GUI.
vSphere Web Client	User logs in to each vCenter Server, just as in the vSphere Client GUI. All Linked vCenter instances can be seen by connecting to any of the vCenter Servers connected in linked mode.	User authenticates to SSO and gets connected to the vSphere Web Client. User gets to view all the vCenter Server instances for which he has permissions. When a user connects to vCenter, he does not have to authenticate any more. The actions that a user can perform on objects depends on his vCenter Server permissions on those objects. For vCenter Server 5.0 or earlier versions, the user must explicitly register the vCenter Server with the vSphere Web Client using the Register vCenter Server link.

Notes:

• Before you can connect to a vCenter Server 5.0 system with vSphere Web Client 5.1, you must register it with the vSphere Web Client.
• You can register multiple vCenter Server systems with a single vSphere Web Client.
• Register a given vCenter Server system with only one vSphere Web Client instance, rather than using multiple vSphere Web Client instances to manage that vCenter Server system.
• To register a vCenter Server system with the vSphere Web Client installed as part of a vCenter Server Appliance, you must use the admin-app command-line script, rather than the Web-based administration tool.

For more information, see the Using the vSphere Web Client Administration Tool section of the vCenter Server and Host Management Guide.

Behavior when using the vSphere API

Behavior	vCenter Server 5.0 or earlier	vCenter Server 5.1
vSphere API	User logs in to each vCenter Server using userid/password or SSPI	User has to authenticate to SSO using userID and password or SSPI. Upon successful authentication, user gets a SAML token. User passes the token to vCenter Server.

For more information on using the vSphere API, see the vSphere Management SDK Guide.

Behavior of SSO Instance

Behavior	vCenter Server 5.0 or earlier	vCenter Server 5.1
SSO to vCenter Server ratio	Not Applicable	A single SSO instance can support multiple vCenter Server and Inventory Service(IS) instances. During the very first installation, all three components (SSO, IS, VC) must be installed. During subsequent installations SSO need not be installed. IS and vCenter Server can be pointed to an existing SSO service. The installer provides a way to specify that information.

For more information on the SSO instances, see the vSphere Installation and Setup Guide.

SSO Deployment modes

Behavior	vCenter Server 5.0 or earlier	vCenter Server 5.1
Basic	Not Applicable	A standalone version of SSO is installed and multiple vCenter Server and IS instances can point to it. If the SSO service or the virtual machine hosting the service dies, administrators cannot access vCenter Server, but the ESXi hosts continue to function normally. Multiple AD and OpenLDAP instances can be added as identity sources.
Cluster	Not Applicable	Two or more SSO instances are installed in HA mode. They use the same database and should be pointed to the same Identity sources. SSO admin users, when connected to the vSphere Web Client, see the primary SSO instance.
Multisite	Not Applicable	SSO instances are deployed in geographically dispersed datacenters. In each datacenter, SSO can be installed in a standalone or clustered mode, pointing to the identity sources in that location. Active Directories or OpenLDAP instances need to be replicated between these locations.

Notes:

• vCenter Server instances in linked mode can be connected to different physical Single Sign On servers, but must be connected to a single logical Single Sign On server. A single logical Single Sign On server can take any of these forms:
  
  
  • A single physical Single Sign On server
  • Two nodes of a cluster
    
    Note: This is the same as a single physical Single Sign On server because the nodes use the same Single Sign On database.
    
  • Two nodes in multisite mode.

For information about SSO Deployment modes, see the vSphere Installation and Setup and vSphere Security Guides.

Source of this Info:-

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