Categories
Uncategorized

Taking on the unknown: #VMware 4.1 upgrade and how to move from 32bit to 64bit vCentre host and keep your data

The internal setup I run here at Corylus towers is a largely standard VMware ESX installation of SME proportions but with Enterprise style licencing.  One of the anachronisms is that as a test bed rather than “full production” I have the vCentre installed away from the cluster.  In this way if my testing borks it, then I can still manage a recovery.
In addition, having a legacy from 3.0 days the vCentre box is a 32bit windows with 32bit MSDE (again, self-contained for manageability and recovery).
Well, now that 4.1 is around, the vCentre box has to be on a 64bit windows environment.  So an in place upgrade is not possible.  So I checked out the notes from VMware and found only this to cover my situation: Migrating an existing vCentre Server database to 4.1 using the Data Migration Tool.  So the migration looks interesting, but it’s only going to apply to a limited number of clients.  So I thought I would try to manually migrate the box.
First up, was to create a clean Windows 2008 R2 64bit box.  This done (and a snapshot taken for quick restarting of the upgrade process), I thought I’d try installing vCentre 4.0 update 2 on the machine first and see what plays.  I get the MSDE installation, and then with Windows Update, get it patched.  9.0.4053 is the SP3 version number.  On top of that goes the Management Studio Express Console so that I can do backups etc.
Now I know that the MSDE is 32bit, but it is listed as a supported Database for the vCentre at Upgrading to ESX 4.1 and vCenter Server 4.1 best practices  and given that the source database from my old vCentre machine is MSDE, this might make the issue a bit easier to work with.  I then decided to remove vCentre and vOrchestrator so that the vCentre installation was clean and then restored my current VCDB and UMDB.
VCDB restored OK, and then UMDB was attempted – because of the transition from 32bit host to 64bit host I had to change the database paths accordingly [program files (x86)] but the restores went fine.  To satisfy myself, I took a look at a few tables, and all seemed well.  Finally, I created the 64bit System DSN (make sure to create it with the Native Client and not the SQL Server client) to the vCentre database and was ready to go.  Note the DSN should also have the default database changed from Master to VIM_VCDB.
You might also want to create the appropriate AD user account for the installation and grant that the necessary Database permissions (and account) in MSDE so that
So, mount the ISO for 4.1 and go!
It’s the usual VMware CD/DVD experience at first, choose vCentre Server and then go for a nap as the installer “prepares”, then you get a welcome screen (and then take another nap whilst the Next button is greyed out).  Then be prepared to be amazed at the list of patents VMware wants to protect, then you start doing the real stuff.
You pick up the DSN that you created earlier, and then get the chance to tell the install to upgrade the database (you even have to confirm that you took a backup!) and then eventually click Go.  At this point the database is upgraded and you can get another coffee, maybe a pizza and sit back and relax – my choice was Tora! Tora! Tora!
Later that day…. I read this: Upgrading to vCenter 4.1 with bundled SQL Express Edition – database migration fails and decided I’d probably taken the correct route

By P J Bryant

Ramblings of a freelance IT Consultant working for some nice SME's, large organisations, resellers and the usual friends and family! Bit of

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s