Monday, August 26, 2013

Mistakes when using CPU reservations to solve "CPU Ready" issues

I recently came across this article by Josh Odgers. Good writeup on how to monitor and watch for CPU ready issues within your environment.

What is CPU Ready?
CPU ready is basically the time it takes a VM to be scheduled onto physical core after it is placed in the CPU scheduling queue.

What is High CPU Ready?
In my opinion, during peak load, anything above 2% (or 400ms) is a concern and should be monitored. Above 5% will be impacting performance (resulting in lower CPU utilization) and 10% or more, should be considered a serious problem and remediated immediately.
The below is a screenshot showing CPU ready from a recent test I conducted in my home lab


To calculate the percentage of CPU Ready, we divide the VMs “Summation” value (in the screen shot above its the “W2K8 CPU TEST VM 1″ line by 20000 (ms) which is the statistics collection interval, then divide the result by the number of vCPUs in the VM.
So if we use the value from the “latest” column, its 7337 divide 20000, equals : 0.36685, then we divide that by 2 as the VM has 2 vCPUs and we end up with 0.183425
That’s 18% CPU Ready, which basically means 18% of the time, the VM is not doing anything!
Note: CPU Ready % can be found using ESXTOP or RESXTOP via the vMA or on the ESXi host directly.
Now to try and diagnose the Performance/CPU ready issue, we need to work out if the VM is oversized and if so, Right Size the VM.

What is an Oversized VM?
Basically a VM which has more compute resources assigned than it requires, for example, a VM which uses no more than 20% of its CPU and has 4 vCPUs.

What is Right Sizing?
In the above example, the VM is oversized as it doesn’t use more than 1vCPU (or 25%) of the CPU resources and therefore could be reduced to to 1 vCPU and run at 80%.
So the VM is oversized, and has High CPU ready, what happens when we right size it from 4vCPUs to 1vCPU and why does this help performance?
Its pretty simple, the less vCPUs a VM has, the easier job the CPU scheduler has to find enough physical cores to schedule the VM onto. If a cluster has a lot of oversized VMs, all the VMs are all competing for the same physical cores, and making it more and more difficult for the scheduler.
But what about setting a CPU Reservation? Don’t reservations “guarantee” resources?
The answer is, Yes and No.
The reservation “reserves” CPU resources measured in Mhz, but this has nothing to do with the CPU scheduler.
So setting a reservation will help improve performance for the VM you set it on, but will not “solve” CPU ready issues caused by “oversized” VMs, or by too high an overcommitment ratio of CPU resources.
In my testing I set an 80% reservation of a VMs 2 vCPUs worth of Mhz and prior to setting the reservation the CPU ready was ~20% and then CPU Ready did drop to around 10%.

Note: This test was performed with only 25% overcommitment – 5 vCPUs on 4 physical Cores using CPUBUSY to keep the CPUs running at 100% (measured within the guest by Windows Task Manager). I then set a 100% reservation of the VMs 2 vCPUs worth of Mhz, prior to setting the reservation the CPU ready was ~10% and CPU Ready did not get below 2.5% even with 100% reservation.
The result would have been exponentially worse had I tested with 50% or 100% overcommitment which is generally easily achieved with VMware and a well architected cluster. (I have seen well above these overcommitment numbers with no CPU ready issues).
Reducing CPU Ready down to 2.5% may sound like a pretty good result, but when we look at the other 3 x 1vCPU VMs on the host (4 core test ESXi 5 host) they had CPU ready of 40%!! Not to mention 2.5% is still not good!

If you have poor performance, and you discover you have High CPU Ready the best solution is   

Right Size Your VMs!
I have recommended exactly that countless times and the customers never believe that performance can increase with less vCPUs, until after the Right Sizing exercise. If after Right sizing, you still have CPU Ready, your overcommitment on CPU is simply to high for the workloads within your cluster.
You can address this by

1. Adding additional compute to the cluster. (Duh!)
2. Using Affinity rules to locate complimentary workloads together (Lots of small 1vCPU VMs which don’t have high CPU utilization will generally work well with a limited number of higher vCPU VMs)
3. Use Anti-Affinity rules to separate non complimentary workloads (eg: Don’t place all your 8vCPU VMs on one host with 300% overcommitment on CPU and expect them to work well).
4. Scaling out (not up) your VMs ie: Don’t have one 8 vCPU SQL DB server, use 4 smaller 2vCPU VMs
So now you know better than to use reservations to solve CPU contention.

View Desktops - Black screen after logging on- PCOIP connection fail

This issue may occur when VMware Tools is installed or upgraded after installing VMware View Agent. The set of VGA drivers shipped with VMware Tools might sometimes be incompatible with VMware View and PCoIP, whereas the VMware View Agent software contains a supported VGA driver.

To resolve this issue, you must update the drivers to the version supplied with VMware View Agent.
To update the drivers:
  1. Log in to the affected virtual machine. If your desktop pool exhibits this behavior, log into the parent virtual machine or the base image.
  2. Click Start > Run.
  3. Type devmgmt.msc, and click OK. The Device Manager window of the virtual desktop opens.
  4. In the Display Adapters subsection, locate the entry for VMware SVGA.
  5. Right-click the driver and click Update Driver.
  6. Update the driver to the version supplied with VMware View Agent located at:

    C:\Program Files\Common Files\VMware\Drivers\video

    Note:
    • For View Agent 5.0.x – C:\Program Files\Common Files\VMware\Drivers\wddm_video
    • For View Agent 5.1.x – C:\Program Files\Common Files\VMware\Drivers\video_wddm
    • For Windows XP – C:\Program Files\Common Files\VMware\Drivers\video_xpdm
NOTE: If this does not resolve your issue, you may have to uninstall VMware Tools and VMware View agent and reinstall them in the correct order.

For more information, see Configuring PCoIP for use with View Manager (1018158).

 

Additional Information

This table lists video drivers supplied with different VMware View Agent versions and operating systems:


Windows XP Windows Vista Windows 7 Windows 8
View 3.1.3 build 252693
VMware SVGA II
Version: 11.6.0.35
Dated: 4/21/2010
VMware SVGA 3D
Version: 17.14.1.42
Dated: 4/21/2010
Not Supported Not Supported
View 4.0.2 build 294291
VMware SVGA II
Version: 11.6.0.35
Dated: 4/21/2010

Not Supported Not Supported
View 4.5.0 build 293049
VMware SVGA II
Version: 11.6.0.37
Dated: 7/16/2010
VMware SVGA II
Version: 11.6.0.37
Dated: 7/16/2010
VMware SVGA 3D
Version: 7.14.1.49
Dated: 7/16/2010
Not Supported
View 4.6.0 build 366101
VMware SVGA II
Version: 11.6.0.37
Dated: 7/16/2010
VMware SVGA II
Version: 11.6.0.37
Dated: 7/16/2010
VMware SVGA 3D
Version: 7.14.1.49
Dated: 7/16/2010
Not Supported
View 4.6.3 build 1032953 
VMware SVGA II
Version: 11.6.0.39
Dated: 11/16/2011

VMware SVGA 3D
Version: 7.14.1.1052
Dated: 11/16/2011
Not Supported
View 5.0 build 481677 VMware SVGA II
Version: 11.7.5.0
Dated: 7/12/2011
VMware SVGA II
Version: 11.7.5.0
Dated: 7/12/2011
VMware SVGA 3D
Version: 7.14.1.1061
Dated: 7/29/2011
Not Supported
View 5.0.1 build 640055 VMware SVGA II
Version: 11.7.5.0
Dated: 7/12/2011
VMware SVGA II
Version: 11.7.5.0
Dated: 7/12/2011
VMware SVGA 3D
Version: 7.14.1.1063
Not Supported
View 5.1.0 build 704644 VMware SVGA II
Version: 11.7.20.0
Dated: 4/17/2012

VMware SVGA 3D
Version: 7.14.1.1080
Dated: 4/17/2012
Not Supported
View 5.1.1 build 799444
VMware SVGA II
Version: 11.7.20.0
Dated: 4/17/2012

VMware SVGA 3D
Version: 7.14.1.1080
Dated: 4/17/2012 
Not Supported
View 5.1.2 build 928164
VMware SVGA II
Version: 11.7.20.0
Dated: 4/17/2012

VMware SVGA 3D
Version: 7.14.1.1208
Dated: 11/07/2012
Not Supported
View 5.1.3 build 1007228
VMware SVGA II
Version: 11.7.20.0
Dated: 4/17/2012

VMware SVGA 3D
Version: 7.14.1.1208
Dated: 11/07/2012
Not Supported
View 5.2.0 build 987719 VMware SVGA II
Version: 11.9.1.0
Dated: 2/17/2012

VMware SVGA 3D
Version: 7.14.1.1235
Dated: 1/10/2013
VMware SVGA 3D
Version: 7.14.1.1235
Dated: 1/10/2013

Friday, August 23, 2013

vCenter - Impact of Memory Reservations vs Resource Pools

Here's a good article I came across by Mark Denneman. I thought I had a good understanding of memory reservations when I initially started setting up my clustered environment but after reading through his article and a few changes to my clusters it cleared up some misconceptions. I definitely noticed a big performance jump for my entire Virtual infrastructure. My setup wasn't entirely wrong but was definitely strained because of the VM memory and CPU reservations I had in place which did affect other systems within my environment.

After a few changes, creating new resource pools (Parent and Child pools) and removing VM memory and CPU reservations, My "Runtime Info" within my Server Cluster went from 17 to 546 "Available Slots". My Workstation Cluster went from 35 to 1683 "Available Slots". That alone doesn't necessarily mean I gained performance, it means I now have room for failover slots and more VM's if I choose to add more. I did run "Performance" monitoring on some of my heavy user VM's and did notice much improvement. Prior to the changes many of my VM workstations were maxing out CPU and Memory resources and now after making those changes none of my VM's have pegged out...I've had one or two hit the warning alarm but none have hit the Critical alarms anymore.

Note:
We run a unique environment in that our VDI cluster demands CPU and Memory resources because of the work that is being performed. Keep in mind that these aren't everyday Office and Web (internet) type users we have. These are Aerospace and Mechanical Engineers running different modeling and simulation programs along with statistical analysis creation and gathering. Yes, these VM's are really being used and pushed to their limits.

Is there any difference between resource pool level and virtual machine level memory reservation?
To keep it short, VM level reservation can be rather evil, it will hoard memory if it has been used by the virtual machine once. Even if the virtual machine becomes idle, the VMkernel will not reclaim this memory and return it to the free memory set. This means that ESX can start swapping and ballooning if no free memory is available for other virtual machines while the owning VM’s aren’t using their claimed reserved memory. It also has influence on the slot size of High availability, for more information about HA slot sizes, please visit the HA deep dive page at yellow-bricks.com. For more information about virtual machine level memory reservation, please read the article “impact of memory management“.

Behavior of resource pool memory reservation
Now setting a memory reservation on a resource pool level has its own weaknesses, but it is much fairer and more along the whole idea of consolidation and sharing than virtual machine memory reservations. RP level reservations are immediately active, but are not claimed. This means it will only subtract the specified amount of memory from the unreserved capacity of the cluster.
RP reservations are used when children of the resource pool uses memory and the system is under contention. Reservations are not wasted and the resources can be used by other virtual machines. Be aware, using and reserving are two distinct concepts! Virtual machines can use the resource, but they cannot reserve this as well if it is already reserved by another item.
It appears that resource pool memory reservations work almost similar to CPU reservations, they won’t let any resource go to waste. And to top it off, resource pool reservations don’t flow to virtual machines, they will not influence HA slot sizes. Which unfortunately can lead to (temporary) performance loss if a host failover occurs. When a virtual machine is restarted by HA they are not restarted in the correct resource pool but in the root resource pool, which can lead to starvation. Until DRS is invoked, the virtual machine need to do it without any memory reservations.


Memory reservation technique
Let’s get back to memory reservation .How does ESX handle memory reservation? Page 17 of the Resource Management Guide states the following:
Memory Reservation
If a virtual machine has a memory reservation but has not yet accessed its full reservation, the unused memory can be reallocated to other virtual machines.
Memory Reservation Used
Used for powered‐on virtual machines, the system reserves memory resources according to each virtual machine’s reservation setting and overhead. After a virtual machine has accessed its full reservation, ESX Server allows the virtual machine to retain this much
memory, and will not reclaim it, even if the virtual machine becomes idle and stops accessing memory.
To recap the info stated in the Resource Management Guide, when a VM hits its full reservation, ESX will never reclaim that amount of reserved memory even if the machine idles and drops below its guaranteed reservation. It cannot reallocate that machine memory to other virtual machines.

Full reservation
But when will a VM hit its full reservation exactly? Popular belief is that the VM will hit full reservation when a VM is pushing workloads, but that is not entirely true. It also depends on the Guest OS being used by the VM. Linux plays rather well with others, when Linux boots it only addresses the memory pages it needs. This gives ESX the ability to reallocate memory to other machines. After its application or OS generates load, the Linux VM can hit its full reservation. Windows on the other hand zeroes all of its memory during boot, which results in hitting the full reservation during boot time.

Full reservation and admission control
This behavior will have impact on admission control. Admission control on the ESX server checks the amount of available unreserved CPU and memory resources. Because Windows will hit its full reservation at startup, ESX cannot reallocate this memory to other VMs, hereby diminishing the amount of available unreserved memory resources and therefore restricting the capacity of VM placement on the ESX server. But memory reclamation, especially TPS will help in this scenario, TPS (transparent page sharing) reduces redundant multiple guest pages by mapping them to a single machine memory page. Because memory reservation “lives” at machine memory level and not at virtual machine physical level, TPS will reduce the amount of reserved machine memory pages, memory pages that admission controls check when starting a VM.

Transparant Page Sharing
TPS cannot collapse pages immediately when starting a VM in ESX 3.5. TPS is a process in the VMkernel; it runs in the background and searches for redundant pages. Default TPS will have a cycle of 60 minutes (Mem.ShareScanTime) to scan a VM for page sharing opportunities. The speed of TPS mostly depends on the load and specs of the Server. Default TPS will scan 4MB/sec per 1 GHz. (Mem.ShareScanGHz). Slow CPU equals slow TPS process. (But it’s not a secret that a slow CPU will offer less performance that a fast CPU.) TPS defaults can be altered, but it is advised to keep to the default.TPS cannot collapse pages immediately when starting a VM in ESX 3.5. VMware optimized memory management in ESX 4; pages which Windows initially zeroes will be page-shared by TPS immediately.

TPS and large pages
One caveat, TPS will not collapse large pages when the ESX server is not under memory pressure. ESX will back large pages with machine memory, but installs page sharing hints. When memory pressure occurs, the large page will be broken down and TPS can do it’s magic. More info on Large pages and ESX can be found at Yellow Bricks. http://www.yellow-bricks.com/2009/05/31/nehalem-cpu-and-tps-on-vsphere/

Use resource pools
Setting memory reservation has impact on the VM itself and its surroundings. Setting reservation per VM is not best practice; it is advised to create resource pools instead of per VM reservations. Setting reservations on a granular level leads to increased administrative and operational overhead. But when the situation demands to use per VM reservation, in which way can a reservation be set to guarantee as much performance as possible without wasting physical memory and with as less impact as possible. The answer: set reservation equal to the average Guest Memory Usage of the VMs.

Guest Memory Usage
Guest Memory Usage shows the active memory use of the VM. Which memory is considered active memory? If a memory page is accessed in mem.sampleperiod (60sec), it is considered active. To accomplish this you need to monitor each VM, but this is where vCenter comes to the rescue. vCenter logs performance data and does this for a period of time. The problem is that the counters average-, minimum and maximum active memory data is not captured on the default vCenter statistics. vCenter logging level needs to upgraded to a minimum level of 4. After setting the new level, vCenter starts to log the data. Changing the statistic setting can be done by Administration > VirtualCenter Management Server Configuration > Statistics.


To display the average active memory of the VM, open the performance tab of the VM and change chart options, select memory


Select the counters consumed memory and average-, minimum- and maximum active memory. The performance chart of most VMs will show these values close to each other. As a rule the average active memory figure can be used as input for the memory reservation setting, but sometimes the SLA of the VM will determine that it’s better to use the maximum active memory usage.


Consumed memory is the amount of host memory that is being used to back guest memory. The images shows that memory consumed slowly decreases.
The active memory use does not change that much during the monitored 24 hours. By setting the reservation equal to the maximum average active memory value, enough physical pages will be backed to meet the VM’s requests.

Thursday, August 15, 2013

VMware Single Sign-On - "Warning 29155: The identity source was not identified automatically"

VMware vSphere 5.1 provides Single Sign-On throughout a VMware vCenter instance. VMware Single Sign-On expects Microsoft Active Directory as so-called "Identity Source", but is also able to use other types of user repositories. This article describes how to use UCS 3.1 / Samba 4 instead of Microsoft Active Directory.

Prerequisites

Depending on the size of the environment the number of UCS, Windows and VMware ESXi Hypervisor hosts may vary. Let's assume the following minimum configuration:
  • 1 UCS 3.1 Domain Controller Master with Samba 4
  • 1 Windows Server, member of the UCS 3.1/Samba 4 domain with the following VMware vSphere 5.1 components installed:
            VMware vCenter Single Sign On
            VMware vCenter Inventory Service
            VMware vCenter Server
            VMware vSphere Client
            VMware vSphere Web Client
  • 1 VMware ESXi Hypervisor Host [optional, but reasonable]

 

Known Issues

During the installation of VMware vCenter on the Windows Server the following warning might appear:
Warning 29155: The identity source was not identified automatically.
This warning can be ignored. The identity source will be added manually after the installation finished.

 

Configuration of VMware vCenter Single Sign-On

Start "VMware vSphere Web Client" on the Windows Server or open your vSphere-Client-URL in your browser (usually https://your-vCenter-server:9443/vsphere-client).
Log in with your "admin@System-Domain"-Account that was created during installation of vCenter.
VMware vSphere Web Client

Note: You need to use "admin@System-Domain". Any other account won't be able to add "Identity Sources" at this point. So make sure the account is not disabled or deleted.


Go to AdministrationSign-On and DiscoveryConfigurationIdentity Sources and add a new "Identity Source" (+).


Administration     Add Identity Source   




A new window will open up. Select Active Directory and enter the desired information:
  • a name for this "Identity Source" (e.g. UCS3-SAMBA4)
  • primary ldap-URL consisting of DC Master FQDN and LDAP-Port (e.g. ldap://ucs-master.example.com:389)
  • Optional: secondary LDAP Server, recommended when there's a DC Backup
  • Domain name (e.g. example.com)
  • Domain alias, which is the NetBIOS name of the domain (e.g. EXAMPLE)
  • Authentication Type: Password
  • Username: PrivilegedUser@example.com (domain user with right to read LDAP)
  • Password of the above user


Identity Source configuration



Change to AdministrationAccessSSO Users and Groups → Open Groups → Add a new group (e.g. VMware Domain Admins) → Select this group and click Add Principals
Add group          Add principals


A new window opens up: Select the "Identity Source" we added before (e.g. example.com) and search for your desired LDAP-group (e.g. Domain Admins), then click Add and OK.
Principals



The chosen users/groups are now able to log in with their credentials:
  • username@example.com
  • domain-user password


While using the VMware vSphere Client (not the Web Client), users can now select "Use Windows session credentials".
VMware vSphere Client

 
Note: If a user password is changed or the user is disabled/deleted in your LDAP, this will not affect an active session in VMware vSphere (Web) Client. The changes will have an effect on the next login.

Note: Don't forget to add the right to manage a vCenter server (or single VMs) for the users. This can be done via vCenter → your vCenter serverManagePermissionsAdd permission. Otherwise the users will be able to log in, but won't see any vServers, Datacenters or Hosts.

Tuesday, August 6, 2013

View Connection Server with SmartCard authentication enabled fails with error: Smart Card or Certificate authentication is required (2013044)

This issue occurs if all the required root or intermediate certificates have not been loaded into the keystore on the View Connection servers.
In the DoD space, this issue may also occur if newer CACs are signed by the new root and intermediate certs were released since the keystore was created.

Resolution

To resolve this issue, add the required root or intermediate certificates to the keystore.
To add the required root or intermediate certificates to the keystore:
  1. Log in to the Connection Broker as an administrator.
  2. If the Connection Broker is running Windows 2003 Server or Windows 2008 Server (not R2), install the Microsoft Windows Management Framework Core package to get PowerShell.
  3. If you are a DoD customer using DoD issued CAC cards, perform the steps in the Additional Steps for DoD Customers section below and then go to Step 6.
  4. Using Windows Explorer, navigate to the root of your C drive and create a new folder named Certs.
  5. Copy all root and intermediate certificates required by your organization to validate SmartCards to the C:\Certs folder.
  6. Download the 2013044_make_keystore.zip file from vmware.
  7. Extract the make_keystore.ps1 PowerShell script from the attached .zip file to the C:\Program Files\VMware\VMware View\Server\sslgateway\conf folder.
  8. Click Start > All Programs > Accessories.
  9. Right-click Windows PowerShell and click Run as administrator.
  10. Run this command:

    cd "\Program Files\VMware\VMware View\Server\sslgateway\conf"
  11. Run this command:

    Set-ExecutionPolicy unrestricted 
  12. Answer Y when prompted.
  13. Run this command in a single line:

    .\make_keystore.ps1 -CertDir C:\Certs -Password storepass -KeyStore keystore -LockedProperties locked.propertiesWhere storepass is a password that you want.

    Note: The password must be at least 6 characters and must be enclosed within quotes if it contains spaces or special characters.

  14. Click Start > Administrative Tools > Services.
  15. Right-click the VMware View Connection Server service and click Restart.


Note: A downloadable package of all the DoD root and intermediate certificates is already available. Ensure to follow this procedure with the latest version every few months to make sure new CAC cards authenticate in your environment as new CA certs are released.
  1. Go to the URL https://www.dodpke.com/InstallRoot/ and download the latest version of the InstallRoot#.##wJRE-#u##.msi package.
  2. After the download completes, double-click the downloaded package. You may be prompted with a security warning.
  3. Click Run to continue with the installation.
  4. In the Setup Wizard welcome screen, click Next three times to accept the default settings.
  5. In the Ready to Install scree, click Install.
  6. Click Finish.

    The InstallRoot program should automatically open. If it does not open, start it using the Start menu.

  7. Click Advanced Mode
  8. Click DoD NIPRNet Certificates and then click Select/Deselect All.
  9. Click Export Selected.
  10. Navigate to the root of your C drive and create a new folder called Certs.
  11. Open the Certs folder.
  12. Click OK.

Installing VMware vCenter 5.1 on Windows Server 2008 R2

I'm reposting Adrian Costea's Blog on "Installing VMware vCenter 5.1 on Windows Server 2008 R2". I've ran through this install myself a couple times but it's always good to share the knowledge and not to mention "screen shots" on how to actually perform it. My environments don't allow me to take screen shots...so here you go! Thanks Adrian!

VMware released the new version of vCenter server which is 5.1, with new improvements and features. I’m not going to write them here to bore you, but if you want to read about what’s new you can read this paper. The vCenter server 5.1 installation in this article will use a remote SQL server for the database; installing it using the SQL server Express that comes with the package is just too easy, and maybe you have a large environment so a dedicated SQL server works the best. The installation steps are a bit different compared to the installation of VMware vCenter 5.0 because of the vCenter Single Sign On feature.

Minimum requirements for the vCenter server:

Processor: Intel or AMD x86 processor with two or more logical cores, each with a speed of at least 2GHz.
Memory: 4GB RAM. RAM requirements may be higher if your database runs on the same machine.
Disk storage: 4GB. Disk requirements may be higher if the vCenter Server database runs on the same machine.
Database: Microsoft SQL Server Express for small deployments 5 hosts/50 VMs. Not important for this scenario.
Supported operating systems:
Microsoft Windows Server 2003 Standard, Enterprise or Datacenter SP2 (required) 64bit
Microsoft Windows Server 2003 Standard, Enterprise or Datacenter R2 SP2 (required) 64bit
Microsoft Windows Server 2008 Standard, Enterprise or Datacenter SP2 64bit
Microsoft Windows Server 2008 Standard, Enterprise or Datacenter R2 64bit
For a full list of prerequisites please read this VMware KB.

Before the actual VMware vCenter server installation begins we need to create and configure the databases and users on our SQL server. Let’s start with the vCenter database. Right-click Databases on your SQL server and choose New Database.
Install vCenter 51 on 2008 R2

Type a name for the database in the Database name box then go to the Options page.

Here select Simple on the Recovery model drop-down box. Click OK to create the database.

Since we are not going to use Windows authentication a SQL login needs to be created to be able to connect to the database, later on. Right-click Logins and choose New Login.

Here we have a few settings to change. First type a name for the login. Now select SQL Server authentication, type a password, then remove the check from the Enforce password policy box. On the Default database drop-down box select the database we created a few moments ago. Don’t click OK just yet.

Go to the User Mapping page and check the boxes next to msdb and VMware_vCenter_51 (this is the database we just created). Now on the Default Schema column some buttons appeared. Click the button from the msdb database, go to Browse and from the list select the dbo object. Do this for the other database too. On the Default role member ship section select db_owner for both databases. Click OK.
     

Make sure the SQL Server agent is started and configured to start automatically.


Now that our vCenter server database and login are created, is time to take care of the VMware Single Sign On (SSO) database and logins too. For this we are going to use some scripts from the VMware vCenter Infrastructure 5.1 DVD/ISO. Mount the ISO on the SQL server and browse to Single Sign On\DBScripts\SSOServer\schema\mssql. What we are interested in here are the rsaIMSLiteMSSQLSetupTablespaces.sql and rsaIMSLiteMSSQLSetupUsers.sql SQL queries files.

Double click the first one to open the query in SQL server so we can modify it to our needs and eventually execute it. You need to have the SQL Management Studio already opened and connected to the SQL instance for this to work. As you can see this script will create a database with the name RSA; we need to modify that for a production environment, is just not a great name. Then we need to type a path location for the database files and replace CHANGE ME.
     

I’m going to call the SSO database vCenter_SSO and put the database and log files on a separate partition (E:\vCenterDB). Just replace where you see RSA on the script with vCenter_SSO (if this is the name you want for the database). When your done modifying the script click the Execute button.

The database should be now created and present under the Databases folder.
     

Now we need to create some logins for this database, and we are going to use the rsaIMSLiteMSSQLSetupUsers.sql query file for this. Here I will modify the names of the logins, because I just don’t like the RSA names, put the correct database name in the script, and provide passwords for the two logins. At the end of the CREATE LOGIN line, I will type CHECK_POLICY = OFF so the password policy will not be enforced and have to use a strong password. When your done click Execute.

And voilĂ , the users were created successfully.

Before we log off from this server, verify that SQL server authentication is enabled. Right-click the server name, choose Properties and on the Security page the SQL Server and Windows Authentication mode option should be selected. Restart the SQL server service for the change to take effect.
    





Wow… now those were a lot of steps for just two databases, but we are done now on the SQL server. Let’s move on to the vCenter server, well…the future vCenter server. Since we are using a remote SQL server a System DSN needs to be created on the machine where VMware vCenter will run, but before that the correct SQL driver needs to be installed on this machine. Mount the SQL server ISO, if you are in a virtual environment or put the DVD and launch the wizard. You need to mount the same version of SQL server that you are using for the vCenter server database.
If you don’t have .NET Framework installed, just hit the OK button so the wizard will install it automatically.

Go to the Installation menu on the screen and click the New installation or add features to an existing installation link.

The wizard will check the environment and if everything looks good you can click the OK button to continue.

Type the product key and click Next.


Accept the EULA and continue the wizard.

Hit the Install button to install the setup support files. These files are needed for the SQL installation, and without them you can’t continue.

A software compatibility check is performed before moving forward. If everything looks good and no errors are presented click the Next button to continue.

Make sure SQL Server Feature Installation button is selected and click Next.

All we need to select here is Management Tools – Basic.

Follow to wizard ’till the end using the default settings. Click the Install button to install those SQL Management tools.
    


Now that we have the correct SQL driver present on the system is time to create the System DSN. From Administrative Tools, open Data Sources (ODBC). Go to the System DSN tab and click the Add button.

Select SQL Server Native Client 10.0 and click Finish.


On the new wizard, in the Name box type a name for this System DSN. On the Server box type the SQL server name; this is the server we used earlier to create those databases and logins. Click Next when your done.


Since I’ve said earlier that we are not going to use Integrated Windows authentication for the vCenter database, select the second option here With SQL Server authentication using a login ID and password entered by the user. Type the user and password for the connection, VMware-vCenter_USER for this example.

The correct database should be selected automatically for this user. If not check the Change to default database to box and select the vCenter database from the list.

Leave the defaults here and click Finish.

On the window that pops-up click the Test Data Source button to verify the connection. If passed, click OK and OK again on the ODBC Data Source Administrator window.
    


At last, is time for us to install the vCenter server and the vCenter components. You can install vCenter components (SSO, Inventory Service, vCenter Server) on different machines if you want to, or if the load is heavy for a single machine to handle it. If you go this way you need to install the SSO first, then the Inventory service and the last one is the vCenter server. However, for the sake of this example I’m going to install all the components on a single server, so select VMware vCenter Simple Install from the menu and hit the Install button.

As you can see the SSO wizard is the first one that pops-up for installation. Click Next twice to skip the Welcome screen and the End User Patent Agreement screen.
     

Accept the EULA and continue.

Provide a strong password for the SSO administrator that the wizard will create. Do not forget this password because you might need it sometime to manage the SSO domain.

Since we prepared for a connection with a remote SQL database, select the second option Use an existing supported database.

The database type is Mssql since we are using Microsoft SQL server. For the database name type vCenter_SSO, because this is the database we created for the SSO service. On the Host name or IP address box type the name of your SQL server and leave the port as it is. Check the box next to Use manually created DB users and in the bellow boxes type the username and their credentials we created on the SQL server (VMwareSSO_DBA, VMwareSSO_USER). Click Next.

You might get the error message “Database connection has failed. You can refer to the vm-sso-javaLib.log in the system temporary folder for more information“. To solve this log on to your SQL server and reset the accounts password for VMwareSSO_DBA and VMwareSSO_USER. Just right-click the login account select Properties and in the Password and Confirm Password boxes type the password again and click OK.
     


If your DNS infrastructure is working great then leave the FQDN that the wizard provides as it is and continue the wizard.

You can go with the default option here, or you can provide a service account for the Security Support Provider Interface. Me personally, I don’t like to have services running as local accounts, so I’ve created a domain account for this in AD.

Leave the default path here for the installation and continue.

Again, go with the defaults here and click Next.

Click Install to proceed with the VMware SSO service installation. As soon as is done, the wizard for the Inventory service automatically pops-up and starts installing the service.
     

The first screen for the vCenter wizard is the license screen. You can type your product key now, or continue with the installation and provide it later on.

Select Use an existing supported database and choose the System DNS we created earlier.

Provide the password for the user so the wizard can connect to the database.

I told you I don’t like to use local accounts for the services to run. The vCenter server will run under a domain service account.

Leave the default ports here and click Next.

You need to specify how many VMs and ESXi hosts you will have so the wizard can optimize the deployment. The bigger the infrastructure the more RAM the Web services needs.

At the Ready to install the program page click the Install button to start installing the vCenter server.

At the end click the Finish button to close the wizard. We are done with the vCenter server installation.
     

If you want to verify that it works, and I bet you want, install the client and connect to the vCenter server.
     


Looks like it works, and all this was a success.