The other day, yesterday to be exact, I completed a long standing task of my vSphere Upgrade. Migrate my vCenter Server database from the vCenter Server to a dedicated MSSQL Server. I have always wanted to do this, but licensing and other issues always got in the way. There were three reasons for this change:
- I needed a MSSQL server for other tools such as HP Insight Dynamics
- I have been installing Application Performance Management Tools and it would be very cool to see how vCenter behaves in a dynamic environment
- I have a need to add more hosts and therefore more VMs. So needed the space to grow.
The steps are remarkably simple, if your MSSQL databases are the same version, which mine are as I went through the upgrade process from MSSQL 2000 at the beginning of this migration. These steps are:
- Use the Microsoft SQL Server 2008 Import and Export Data (64-bit) tool to migrate your data from one MSSQL Server to another. Be sure you create new databases on the target MSSQL server and move both your vCenter and VMware Update Manager (VUM) databases.
- Update the 64-bit DSN for vCenter and the 32-bit DSN for VUM
- Follow VMware KB article #1003928 to update the username and password used by vCenter to access the database
- Follow VMware KB article #1015223 to update the username and password used by VUM to access the database
After all that was completed, vCenter connected and worked just fine. I had no data loss, which is what I wanted. But VUM did not work. I received ‘Failed to Load’ errors when looking at the VUM screens. A search of VMware’s KB articles and VMTN stated I needed to upgrade to VUM version 4.1 Update1, which I did. The problem persisted. All in all not a very good way to end the day.
So I asked myself, is the VUM data all that important to me? In some ways it is, but in many it is just not that important, the same information is already on each ESX host (when updates occurred). So with this realization, I reinstalled VUM and choose to use a Fresh Database. Viola, VUM started working again. So apparently VUM encodes something into the database which caused this failure, but since the update data is retrievable from VMware, using the old database was not all that important to me.
For those who use VUM to upgrade VMs or have lots of hosts, VUMs database may be important to you but since I only use VUM for hosts and not VMs and I had other means to find the same data, it was not a huge issue. My major issue was preserving my vCenter database, which this method of migration did admirably.
So now do I remove MSSQL 2008 from my vCenter server or leave it. I choose to leave it as vCenter requires the SQL Native Client 10.0 and there is a chance if I remove all of MSSQL 2008, the client will also be removed as it is not a normal part of Windows 2008-R2 but I did remove the old data.
