Upgrade Paths for vCenter Server 32-bit/4.0 to 64-bit/5.0

[derekb13]

So, for various reasons outside of my control, when we installed vCenter server when we migrated from 3.5 to 4.0, it was installed on Windows 32-bit.

The data is backended by a full-blown SQL Server instance (not the MSDE version that comes pre-packaged with vCenter).

So I'm trying to figure out the least-impactful strategy for moving to 5.0.

One idea I've had is simply to build a new "home" for vCenter Server on x86-64, and point the application at the existing database running on the 32-bit windows server. (I'm guessing the 32/64-bit nature of the database server itself is largely irrelevant so long as it allows the 64-bit vCenter Server to talk to it). I would think then that all the cluster information would all remain intact since it's in the database, etc.

If I had to, I suppose, we could install vCenter 4.0 (64-bit) on the new host, and THEN do the upgrade, if that was really important, but I somehow don't think it is.

Once that was done, we'd eventually just do a backup/restore type upgrade path to move the database off the old host, and onto the new host, and re-point vCenter Server at its now-local database.

Has anyone done anything similar to this? Any pitfalls we should be on the lookout for? Warnings that this will never work the way we think it will, etc., etc.?

[Troy_Clavell · Accepted solution]

One idea I've had is simply to build a new "home" for vCenter Server on  x86-64, and point the application at the existing database running on  the 32-bit windows server. (I'm guessing the 32/64-bit nature of the  database server itself is largely irrelevant so long as it allows the  64-bit vCenter Server to talk to it). I would think then that all the  cluster information would all remain intact since it's in the database,  etc.

This is what I would do.  It your DB is remote, it's a pretty straight forward upgrade.

1.  Power down your old vCenter Instance

2. Backup your DB instance

3.  Copy the SSL directory out of the old vCenter and into the new (you'll probably have to manually create the path, prior to installing vCenter)

4. Setup your ODBC Connection and test

5.  Install vCenter and use existing DB

Assuming you're going to use the same hostname and IP address for your new vCenter instance, as your old, all inventory will be as it was prior to the upgrade.

[derekb13]

The DB server isn't, technically, remote, but there's no reason to believe that it couldn't BECOME remote, by the new vCenter host referencing the DB on the old vCenter host, correct?

So long as I configured the old host to allow remote connections, etc., etc.

[Troy_Clavell]

Derek Balling wrote:

The DB server isn't, technically, remote, but there's no reason to believe that it couldn't BECOME remote, by the new vCenter host referencing the DB on the old vCenter host, correct?

So long as I configured the old host to allow remote connections, etc., etc.

correct.  you can use the old vCenter as your new SQL box.  With that said, you'll need a new hostname and IP address for your vCenter Host OS.  Also, once you connect back to your existing DB during the vCenter install, when complete your hosts will probably come back in a disconnected status.  You'll need to "connect" each host the get the new HA and vCenter agents pushed.  They will be disconnected because you changed the hostname of your vCenter instance.

[derekb13]

Or I could just re-ip/hostname the existing (old vCenter / DB Host) to a new hostname like, say, "vcdb", and let the new box inherit the IP/Hostname.

Which is probably what I'd want to do anyway, since people are used to logging into "vCenter" to get to the windows VM they do their work from.

[Troy_Clavell]

yes, that will work too.