RSS

Tag Archives: vCenter 5.5

Fast web client with vCenter 5.5 U3

Great news if you are on ESXi 5.5 estate, VMware recently announced Update 3 with significant improvement to the web client, taken from version 6.

https://blogs.vmware.com/vsphere/2015/11/significant-performance-improvements-come-to-the-vsphere-web-client-5-5-update-3.html

 

 
Leave a comment

Posted by on December 1, 2015 in vmware

 

Tags: ,

PowerShell: Setting JVM heap sizes for vCenter server 5.x

One of the changes from vCenter 5.0 to 5.1 that affect java memory allocation is vFabric tomcat server. This server effective decouples the java heap size memory management to the various vCenter server components, when this used to be a single setting in the tomcat configuration. An effect of this is that you many need to adjust the JVM heap size of your vCenter after upgrading (or even fresh install), even though you have specific the correct sizing during install.

From my experience, since we had upgraded vCenter from 5.0 to 5.5, the JVM heap size may not be sized correctly after the upgrade. Especially the Inventory servces, which can impact performance is set too low. Read the rest of this entry »

 
Leave a comment

Posted by on July 10, 2015 in powershell, Scripts, vmware

 

Tags: , ,

vCenter server SQL database custom DB schema and Windows authentication

What is the standard method of provisioning a new SQL database for your vCenter server? In most organisation, it would be something like this:

  • DBA will create a new SQL login account
  • DBA will create the blank database (with required configurations, of course) and grant db owner role to the account
  • You install vCenter and specify to use SQL login credentials

This is probably this simplest and quick way to setup the SQL database. Now what if, due to regulatory commitments and best practices, your DBA tells you that you had to use Windows authentication instead and NOT use the db owner roles?

Well, switching over to Windows authentication is straight forward enough, but how not to use the db owner role? Well, if you are installing a brand new vCenter, then the setup is quite straight forward. In the vCenter 5.5 installation guide, sections “Create a SQL Server Database and User for vCenter Server” (page 33) and “Use a Script to Create a Microsoft SQL Server Database Schema and Roles” (page 36) details how this can be done.

This will create a custom DB schema to grant permission to the vpxuser account. With the new custom DB schema, the vpxuser must be in VC_USER_ROLE for regular operations and VC_ADMIN_ROLE during installation and upgrades

Now if you have an existing vCenter 5.x server and need to migrate over to a custom DB schema, more work is required. The main details are described in VMware KB 1036331. There are no shortcuts, you do need to read through the steps and work out together with your DBA on how to get it migrated.

Note:

1. The KB contains two attached files, IMHO, DBO_VCDB_objects.zip if redundant since it already exists in Upgrade-Remove-DBO-Role.zip

2. After unzipping Upgrade-Remove-DBO-Role.zip, rename all the files by remove “Upgrade-Remove-DBO-Role” prefix. If you keep the file name as is, the script will fail.

3, For both VCenterUSER and VCUSER, you can only use a local SQL account, the script will fail if VCenterUSER is a domain account, i.e. domain\user syntax. If you are already using Windows authentication, you need to modify the script before use.

The steps can be summarized as follows (assuming that you are migrating to a custom DB schema AND from a local SQL account, since I already mentioned that you will probably fail if you use the attached script with Windows authenticated account, without modifying the script:

Phase 1 (Migrating to custom DB schema)

  1. Stop all vCenter server services
  2. Modify both the verify and upgrade scripts with correct values and send them to your DBA
  3. DBA will execute the verify scripts for any errors
  4. If there are no errors, DBA will execute the upgrade script
  5. Start vCenter server services and perform sanity checks on the vCenter, e.g.perform some vmotion

Phase 2 (Migrating to Windows authenication)

  1. Again, stop all vCenter server services
  2. Get DBA to run the SQL script below
  3. Get DBA to change all scheduled tasks from local use to the domain account
  4. In Windows, type “runas /user:<domain service account> cmd”, this will start an elevated cmd prompt
  5. Navigate to C:\Windows\System32 and run odbcad32.exe (Alternatively, you can look for the ODBC icon and runas a different user)
  6. Reconfigure ODBC for Windows authentication and test your ODBC connection
  7. Restart all vCenter servicer services
  8. Perform sanity check on vCenter, e.g. run some vmotion.
USE [master]
CREATE LOGIN [domain\vpxuser] FROM WINDOWS
WITH DEFAULT_DATABASE=[VPX DB]
USE [VPX DB]
CREATE USER [domain\vpxuser] FOR LOGIN [domain\vpxuser] WITH DEFAULT_SCHEMA=[VMW]

Note: If you are also migrating the VUM service account to Windows authentication, you need to launch (runas) the 32-bit ODBC in C:\Windows\SysWOW64 instead.

 
2 Comments

Posted by on April 10, 2015 in vmware, Windows

 

Tags: ,

vSphere SSO 5.5 does not add default domain after installation and vdcidentitysource nuance

We are in the midst of upgrading vCenters to 5.5 from 5.0. The biggest difference is the inclusion and requirement for SSO server.

The default install of the SSO server is simply enough. After install SSO, we would go ahead to install vCenter server (or upgrade it), it would fail during installation. The reason for failure is the vCenter service would fail to start up with the domain system account. Logging on from web sphere client, we could see that the default computer domain (let’s call this MYAD), which is also the same domain as the system account, was not added as the identity source in SSO. As a result, the system account could not authenticate via SSO and service will not start during installation. Once we added the domain into SSO, the services started up fine. So this is indeed a case of missing identity source in SSO.

During SSO installation, you can select to add the default domain during installation. However, in our case, this never worked. So we had to fire a support question to vmware support. After some weeks of logs and testing, this is what they concluded:

“Based on the uploaded logs, SSO cannot get domain controller info and trust info via DsGetDcName and DsEnumerateDomainTrusts windows APIs and this is causing the delay in finishing up the process of retrieving the domain join status. Installer needs the the domain join info in order to add the current machine’s domain as an IDP. In your setup, by the time we get all the DC and trust info, installer had already asked for that detail and it can’t get it. So it completes the installation without adding the IDP.

Our Engineering team has confirmed that this behavior is by design. I know that you would want this process to be automated, however, they are recommending to use the article http://kb.vmware.com/kb/2063424 to add the Identity Sources after the installation.”

In summary, because our domain has too many trusts, including some that are behind firewall and it took too long to collect the information during installation. Hence, SSO is designed to give up but mark installation as completed. The problem with this is that SSO install should at least warn you that the domain is not successfully added and save the headache of folks installing vCenter server afterwards but scratching their heads why it failed.

So we loaded up the batch files provided and copied all files to c:\vdcidentitysource (note that this path was in the original article, it was later amended because I found the issue with it). So when I executed “sso-add-native-ad-idp.cmd myad.com”, I got the following message:

Error: Could not find or load main class com.vmware.identify.migration.ImporterToSSo2

As this was a test environment, I revert to previous snapshot and ensure I have a really clean environment, installed SSO and executed the batch file again. Again I had the same issue. Anyhow, I found out the issue was a flaw logic in the sso_import.cmd file which sso-add-native-ad-idp.cmd calls AND also because we had installed SSO on D drive but the instructions wants you to execute from C drive.

The error occurs in the last 2 lines of sso_import.cmd:

cd %SSO_IMP_DIR%
%JAVA% -cp migrationtool.jar;exporttool.jar;"%SSO_INST_DIR%vmware-identity-idm-interface.jar";"%SSO_INST_DIR%vmware-identity-idm-client.jar";"%SSO_LIB_DIR%commons-codec-1.4.jar";"%SSO_INST_DIR%lib"\*;"%SSO_INST_DIR%\". ^
-ea com.vmware.identity.migration.ImporterToSSO2 %1 %2

The line “cd %SSO_IMP_DIR%” assumes that the current drive in the command prompt is the same as the drive in the variable %SSO_IMP_DIR%. So if your command prompt is “C:\>” and the variable is “c:\temp”, then “cd c:\temp” will change directory successfully, but if the variable is “d:\temp”, “c:\>cd d:\temp” will just change the directory in d: but will not change the current directory, you will still remain in “c:\>” prompt. As a result the java execute will end up in error.

So to execute the KB correctly, you need to place the source in the same volume as where SSO is installed. VMware support guys updated the KB after I found out this issue. 🙂

Now, executing the KB to add the missing IDP was not an instant solution, In our environment, we had to run this 3-4 times before we could successfully get the domain added as I was constantly getting “machine is not properly joined” error.

Addendum: On of our vCenter 5.0 servers, we had to deselect “add default domain” during SSO installation for it to install successfully. Selecting to add the default domain (i.e. our firm’s domain and trust) caused the install Wizard to hang at “Configuring SSO Components…” forever… No idea what caused this as there were not errors reported in the install or sso logs

 
Leave a comment

Posted by on March 11, 2015 in vmware, Windows, Windows CMD

 

Tags: , ,

Fixing vCenter 5.5 server’s database usage monitoring issue in service health status

Sometimes an upgrade with swanky new features may be the opposite of what you want. A good example is the inclusion of database usage monitoring within vCenter 5.5 server’s service status.

If your SQL database was or is provisioned as usual and you install vCenter 5.5 or upgrade to it, you will see the following amber warning when you check the vCenter service health status:

“Unable to monitor database storage usage. Refer to VMware KB 2078305 for details.”

But when you fire up that KB, it tells you nothing on how to resolve this warning but rather tells you how to manage your database. This feature, it seems was available since vCenter 5.0 but it never showed any warning if you did not configure your database. But with 5.5 (or maybe even 5.1, sorry we skipped that version), you are force to deal with this and cannot ignore it.

http://www.boche.net/blog/index.php/2011/09/27/enabling-vcenter-server-5-0-database-monitoring/

The link from boche.net tells you that you need to run the following on your SQL database:

grant VIEW SERVER STATE to [vpxuser] --&gt; where vpxuser is the account used to access the vCenter database

However, after making this configuration, the warning never went away and I gave VMware support a call. And it turns out, an additional configuration is required to fix this. So the full configuration is:

 use master
 go
 grant VIEW SERVER STATE to [vpxuser]
 go
 GRANT VIEW ANY DEFINITION TO [vpxuser]
 go

However, once database monitoring is enable, the status turns red with the following message:

“Database storage space is critically low and affects vCenter Server functionality. Refer to VMware KB 2078305 for details.”

If you manage a virtualized estate in a big enterprise like I do, you will know that it is highly unlikely that the databases are that full or else the DBAs will be pounding on my door daily!

The VMware support guy pointed me to this link -> https://communities.vmware.com/thread/493193

It turns out that with database monitoring turned on, vCenter will alert you on ALL drives space issue on your database server, regardless whether they are used by the database or not. Typically, we have the SQL database running off a Microsoft cluster with a quorum of size 1 GB.

The default threshold alerts is found in vCenter’s advanced settings:

config.vpxd.vdb.space.warningMB value=5000
config.vpxd.vdb.space.alertMB value=1000

So I must have at least 5 GB of free space in ALL drives to keep it green. This is obviously impossible in a clustered environment using disk quorum. Further, we have a system volume where the application is installed and which doesn’t grow over time and has about 500 MB free space most of the time.

Here is the vpxd-xxx.log capture identify the drives which are below the default threshold

 
2015-02-05T20:48:30.686-05:00 [09596 info 'utilvpxdVdb'] [VpxdVdb::GetDBSpaceStatus] WarningThreshold(MB): 5000 AlertThreshold(MB): 1000. Updating Health Message Parameter to
 --&gt; Drive: Q, Free Space:479 MB, Used Space: 0 MB
 --&gt; Drive: H, Free Space:454 MB, Used Space: 2320 MB
 --&gt; Drive: I, Free Space:461 MB, Used Space: 0 MB
 --&gt; Drive: C, Free Space:37381 MB, Used Space: 0 MB
 --&gt; Drive: D, Free Space:66157 MB, Used Space: 0 MB
 --&gt; Total Used Space: 2320 MB, Minimum Free Space: 454 MB

My solution is to set the threshold low so that this status is always green. This is not a problem for us because we don’t need to monitor the disk space on the SQL servers, the DBA team does it and will ping us if disk space is low. However, if you are a do-it-all administrator, ensure that you have other disks monitoring tools when doing this.

config.vpxd.vdb.space.warningMB value=200
config.vpxd.vdb.space.alertMB value=100

This is a case of new features adding more noise of some of us. I hope VMware will update this feature to allow us to selective turn on and off monitoring of each disk and change the threshold for each disk.

 
4 Comments

Posted by on February 12, 2015 in vmware

 

Tags: ,