vCenter Upgrade to v5.x Failed - Useful Tips

Recently I had some fun and games with what should have been a pretty routine process of upgrading a customer’s vCenter 4.1 Server to vCenter 5.0 Update 1, as it turned out it was far from straightforward.

The main background to my issue was that when performing the upgrade of the database, the progress bar did not move after twenty minutes, which indicated that there was an issue somewhere. There are various VMware KB available in relation to the symptoms I observed but none that actually provided the solution. As a general rule before proceeding with an upgrade I would recommend the following:

- Check the Database Size and reduce where you can (The customer in question had a DB of 74GB and Transaction Log of 236GB)

- Run the upgrade logged in as the Service Account used to start the vCenter Services

- Elevate the Database account to ‘sysadmin’ for the purposes of the upgrade only

Some suggested VMware KB Articles include: Database Size 1007453, Upgrade Issues 2011533, 1003960, 1025139

vCloud Automation Center 5.x – Resource Intensive Limits

To help manage your vCAC implementation and the resources on which it depends, vCAC by default places limits on the number of concurrent instances of two particularly resource-intensive operations, machine provisioning and data collection. During a recent vCloud Suite implementation this particular default behavior caught my colleagues and I out as throughput when testing was very slow. On further investigation we established that the default value was two (2).

For our implementation, we were looking to ensure the largest amount of throughput we could possible achieve without unnecessary impact to the platform. We have successfully tested setting this limit to eight (8) which allows eight machines to be provisioned at once. In order to amend this value here’s what you need to do:

1. Log into your vCAC Server where the vCAC Manager Service (vCloud Automation Center) is running

2. Locate the file ‘MachineService.exe.config’ file which can be located in the following directory ‘%SystemDrive%\Program Files x86\DynamicOps\DCAC Server’

3. Locate the following value ‘MaxOutstandingResourceIntensiveWorkItems’ and amend the value to the desired requirement

4. Save the file

5. Restart the ‘vCloud Automation Center’ service

Remember if you’re running a High Availability implementation to amend the setting on the ‘Stand-by’ system.

Enabling PowerShell Functions with SRM - DR of the Cloud

When calling PowerShell functions as part of an SRM (5.1) recovery plan, you need to perform some additional configurations within PowerShell. This can be achieved using the following procedures.

Step 1 - Set the execution level

1. Launch the 32-bit version of PowerShell

2. Run the command 'Set-ExecutionPolicy RemoteSigned'.

Step 2 - Create and configure a PowerShell profile

1. Run the command 'Test-Path $profile', this will verify if a profile already exists for the user. (assuming that one does not exist go to step 2)

2. Run the command 'New-Item $profile -type file -force', this will force the creation of a new profile file.

3. Run the command 'Notepad $profile', this will open the new file in a Notepad session.

4. Enter the following syntax into the file, then save and close:

   Import-Module vCloudDR

   Add-PSSnapin -name VMware.VimAutomation.Core

Next time you start a new PowerShell session, it will load in our custom functions from the vCloudDR module and add in the VMware core cmdlets.

Step 3 - Install the custom modules for PowerShell to call

1. Locate the folder path 'C:\Windows\SysWOW64\WindowsPowerShell\v1.0\Modules'

2. Create a new folder called 'vCloudDR'. NOTE: This folder name must match the name used for the Import-Module command used in the profile in Step 2.

3. Copy your custom module file into the newly created folder

4. To test that the module has been loaded correctly, restart PowerShell and run the command 'Get-Module -ListAvailable' and verify your custom module is listed.