Currently KB 1022104 states the following:

1.     Make sure your database requirements and patch levels are compliant:

Note: For more information, see vSphere Compatibility Matrix and vCenter Server Database Patch and Configuration Requirements. To use an existing database, you will need to provide a 64 bit system DSN which points to the vCenter Server database. Also, ensure that you have created a full backup of your database before proceeding.  If you are using Oracle see Upgrading to vCenter Server 4.1 fails with the error: Trigger, procedure or function created with PL/SQL compilation error (1026331).

o    Microsoft SQL server Database Support:

§  Microsoft SQL Server 2005 Express

Note: Microsoft SQL Server 2005 Express is intended to be used for small deployments of up to 5 hosts and/or 50 virtual machines.

§  Microsoft SQL Server 2005 Standard edition (SP1, SP2, SP3)

§  Microsoft SQL Server 2005 Standard edition (SP2, SP3) 64 bit

§  Microsoft SQL Server 2005 Enterprise edition (SP1, SP2, SP3)

§  Microsoft SQL Server 2005 Enterprise edition (SP2, SP3) 64 bit

§  Microsoft SQL Server 2008 Standard Edition

§  Microsoft SQL Server 2008 Standard Edition 64-bit

§  Microsoft SQL Server 2008 Enterprise Edition

§  Microsoft SQL Server 2008 Enterprise Edition 64-bit

o    Oracle Database Support:

§  Oracle 10g Standard edition (Release 2 [10.2.0.4])

§  Oracle 10g Enterprise edition (Release 2 [10.2.0.4])

§  Oracle 10g Enterprise edition (Release 2 [10.2.0.4]) 64-bit

§  Oracle 11g Standard edition

§  Oracle 11g Enterprise edition

o    IBM DB2 9 Support

§  IBM DB2 Express C

§  IBM DB2 Express Edition 9

§  IBM DB2 Workgroup Server Edition 9

§  IBM DB2 Enterprise Server Edition 9

Note: IBM DB2 database is only supported for vCenter. There is no support for Update Manager or any plug-in that requires a database.

2.     Make a full backup of the vCenter database.

3.     Make sure that you have these permissions:

o    Microsoft SQL:

§  Grant the System DSN user of the vCenter Database db_owner privileges on the vCenter database.

§  Grant the System DSN user of the vCenter Database db_owner privileges on the MSDB database.

Note: The db_owner privileges on the MSDB database are required for installation and upgrade only.

o    Oracle:

§  Grant dba permissions to the vCenter Server user.

4.     Ensure that your ODBC System DSN is using the proper driver and that it is a 64-bit DSN.

Microsoft SQL must use the SQL Native Client driver.

a.     Stop the VirtualCenter Server service. This step is recommended, especially if the vCenter Server database is on a remote system.

b.     Click Start > Control Panel > Administrative Tools > Services > VMware VirtualCenter Server.

c.     Log in to your vCenter Server with a Local Administrator account on your Windows system to run the upgrade.

d.     Ensure no processes are running that conflict with the ports that vCenter Server uses.

e.     Configure any new vSphere 4.1 licences.

Page 69 of the vSphere 4.1 Install guide at https://www.vmware.com/pdf/vsphere4/r41/vsp_41_esxi_i_vc_setup_guide.pdf also provides information concerning the database permissions.

This post brought to you by VMwarewolf

Question: What DB permissions are required after the install of vCenter 4.1?

Companies running VMware have already achieved enormous gains through virtualization. The next wave of benefits will come when they reduce the time and effort required to run and manage VMware platforms. The VMware Infrastructure Software Development Kit (VI SDK) includes application programming interfaces (APIs) that allow developers and administrators to do just that.

Until now, there has been little documentation for the APIs. In VMware VI and vSphere SDK, software architect and author  Steve Jin demystifies the entire VMware VI and new vSphere SDK and offers detailed, task-based coverage of using the APIs to manage VMware more efficiently and cost-effectively in a new book entitled VMware VI and vSphere SDK: Managing the VMware Infrastructure and vSphere.

Author Steve Jin walks readers through using the VI SDK and cloud-computing vSphere SDK to manage ESX servers, ESX clusters, and VirtualCenter servers in any environment–no matter how complex. Drawing on his extensive expertise working with VMware strategic partners and enterprise customers, he places the VI SDK in practical context, presenting realistic samples and proven best practices for building robust, effective solutions. Jin demonstrates how to manage every facet of a VMware environment, including inventory, host systems, virtual machines (VMs), snapshots, VMotion, clusters, resource pools, networking, storage, data stores, events, alarms, users, security, licenses, and scheduled tasks.

This post brought to you by VMwarewolf

VMware VI and vSphere SDK: Managing the VMware Infrastructure and vSphere

When you get around to installing vSphere,  if on a 64-bit Windows host in x86 compatibility mode, a 32-bit DSN is required for the database connection.

If a DSN has been set up through Start > Administrative Tools > Data Sources (ODBC) the vSphere installer won’t be able to use this DSN.

The 64-bit ODBC Administrator tool can be invoked from Control Panel to manage user DSNs and system DSNs that are used by 64-bit processes, but for 32-bit datasources, the 32-bit ODBC Administrator tool is used for Windows on Windows 64 (WOW64) processes.

To set up a 32-bit DSN launch the 32-bit version of the Data Source Administrator. It is located at:
%systemdrive%\Windows\SysWoW64\Odbcad32.exe

The vSphere installer will then be able to detect the DSN and continue the installation.

Please see Microsoft KB article http://support.microsoft.com/default.aspx/kb/942976/en-us for more information.

If you get the error: DSN is pointing to a unsupported ODBC driver

then see KB article: http://kb.vmware.com/kb/1015804

This post brought to you by VMwarewolf

32-bit ODBC DSN for vSphere

The new Knowledgebase blog has just posted a table of brand new (or recently updated) timekeeping articles for VMware products.  A nice one-stop shop for all the time related KB articles. Worth a visit.

This post brought to you by VMwarewolf

All about Time in VMware

There’s a new problem a few customers have reported whereby-

• ESX disconnects randomly from VirtualCenter
• ESX disconnects when performing VI Client tasks from VirtualCenter.
• Tasks randomly timeout after a long idle time
• “An error occurred communicating to the remote host” pops up.

This only refers to Update 3. This issue seem to be affecting customers with firewalls using state-ful inspection, such as a Juniper ISG 2000, Software Revision 6.1.0R3.

The problem occurs because of SOAP timeouts, and this behavior did not exist in VC 2.0.x or 2.5 GA, as they used a different mechanism to communicate with ESX.

A knowledgebase article is in the works, but Engineering is still actively investigating this problem. One work-around that I have seen mentioned (not verified to work!) is as follows:

• Create a dummy VM on each host (e.g. 16 MB RAM, no disk, no network).
• Set CPU affinity to the last core to prevent VMotion.
• Create a new Scheduled Task that performs:
  • Change power state: Power-on dummy VM. Every hour, on the hour.
• Create another Scheduled Task that performs:
  • Change power state: Power-off dummy VM. Every hour, 30 minutes after the hour.

Like I said, Engineering is aware of this issue and actively investigating it.

This post brought to you by VMwarewolf

ESX disconnects randomly or when doing VI client tasks from VC, task randomly timeout after a long idle time