I'm planning the upgrade of an existing VMware Infrastructure 3 (Virtual Center 2.5 + ESX 3.5) to vSphere 4.1, and I'm stuck at upgrading the Virtual Center server and its back-end database.
vSphere 4.1 is only released as a 64-bit software, so it needs a x64 O.S.; this rules out an in-place upgrade of the existing server.
The plan is to install a new Windows Server 2008 R2 server, with SQL Server 2008 (or 2008 R2 if supported), migrate the database and install vCenter 4.1 on the server.
The question: how do I migrate the database?
When performing an in-place upgrade of Virtual Center to vCenter 4.0, the database is automatically upgraded; but this is not the case when installing a new server.
VMware provides an utility to dump the existing database and import it into a new server, but it only works for SQL Server Express (which according to VMware itself should not be used in medium/large production environments); so this is not an option.
I'm unable to find a supported procedure to perform this migration.
Can anybody please help?
Massimo,
I just went through this, and found to to be a bit of a pain simply because VMware forgot to document the simplicity...
You are correct, the "migration tool" only supports SQL Server Express, I'm not sure why and niether are the two VMware Tech Support Agents I spoke with.
To anyone reading this; NOTE that if you are upgrading/migrating SQL Server Express via the Migration Tool you MUST check the DbServerType registry key FIRST! If it is set to Custom the Migration Tools will simply skip all database steps! See this VMware KB article for more information:
Yes it states "fail", what it does not state is that the Migration Tool will "Silently Skip" your database.
In the end all the Migration Tools does is invoke a standard SQL Server T-SQL backup command. YAY! So you simply need to upgrade your existing 32bit vCenter Server, make a backup/snapshot first just in case, then run through the upgrade as if you were going to use the 32bit version in production. This step will apply any database schema changes.
Build your shiny new 64bit server, install all of the bits then use SQL Server Management Studio to do a database backup of the 32bit SQL Server then restore this to your new 64bit server. NOTE: Make sure SQL and vCenter services are all stopped before doing the backup and the restore steps!
After the SQL restore on your new server reboot it and everything will come back to life just as it was only now with all 64bits!
Hope This Helps!
Bill Hilburn, Senior Systems Engineer
StoneAge, Inc.
Hello.
The plan is to install a new Windows Server 2008 R2 server, with SQL Server 2008 (or 2008 R2 if supported), migrate the database and install vCenter 4.1 on the server.
The Windows 2008 (64-bit) or 2008 R2 is a supported OS for vCenter 4.1. You are most likely looking at a SQL Server 2005 database, at least as an interim. SQL Server 2008 isn't supported at all on vCenter 2.5, but SQL Server 2005 is supported on vCenter 2.5, 4.0, and 4.1. You can verify the exact SQL Server versions, and the OS info as well, in the vSphere Compatibility Matrixes.
The question: how do I migrate the database?
Migrate it to a version of SQL Server 2005 that is supported in both vCenter 2.5 and 4.1. SQL Server 2005 Standard Edition (SP1) covers them all. You can use the procedures in kb 7960893 to help move the database. If you ultimately want to be on SQL Server 2008, then use the procedures in kb 7960893 again, after the upgrade to vSphere 4.1.
When performing an in-place upgrade of Virtual Center to vCenter 4.0, the database is automatically upgraded; but this is not the case when installing a new server.
VMware provides an utility to dump the existing database and import it into a new server, but it only works for SQL Server Express (which according to VMware itself should not be used in medium/large production environments); so this is not an option.
I'm unable to find a supported procedure to perform this migration.
For the upgrade procedure, check out the vSphere Upgrade Guide, as it covers a variety of scenarios.
Good Luck!
If you can get away with losing the events/tasks/performance data, I would recommend starting with a fresh DB for vCenter 4.1. 2.5 to 4.1 is a major jump.
If you can get away with losing the events/tasks/performance data, I would recommend starting with a fresh DB for vCenter 4.1. 2.5 to 4.1 is a major jump.
But wouldn't I lose all my VC data this way?!?
You would built a new vCenter, 4.1 environment and then migrate your ESX environment over to the new environment. You would lose task/events/performance data. You would need to build out the new infrastructure by making clusters etc... setting up correct permissions.., then migrate your ESX servers over (basically a disconnect, remove and add).
You would built a new vCenter, 4.1 environment and then migrate your ESX environment over to the new environment. You would lose task/events/performance data. You would need to build out the new infrastructure by making clusters etc... setting up correct permissions.., then migrate your ESX servers over (basically a disconnect, remove and add).
You would need to configure networking from scratch, create and configure resource pools, completely redefine users and roles... this is not a migration, it's a (almost) full reinstall. Definitely NOT the answer I was looking for.
Our environment is fairly large, so we do not use resource pools and have a very limited number of roles that are only applied at the highest levels. It was an easy process for us and worked well. There are numerous posts from people requesting the best process for migrating ESX hosts to new vCenter infrastructures when 4.0 rolled out, so assuming many people have used this "full install" method with success.
Massimo,
I just went through this, and found to to be a bit of a pain simply because VMware forgot to document the simplicity...
You are correct, the "migration tool" only supports SQL Server Express, I'm not sure why and niether are the two VMware Tech Support Agents I spoke with.
To anyone reading this; NOTE that if you are upgrading/migrating SQL Server Express via the Migration Tool you MUST check the DbServerType registry key FIRST! If it is set to Custom the Migration Tools will simply skip all database steps! See this VMware KB article for more information:
Yes it states "fail", what it does not state is that the Migration Tool will "Silently Skip" your database.
In the end all the Migration Tools does is invoke a standard SQL Server T-SQL backup command. YAY! So you simply need to upgrade your existing 32bit vCenter Server, make a backup/snapshot first just in case, then run through the upgrade as if you were going to use the 32bit version in production. This step will apply any database schema changes.
Build your shiny new 64bit server, install all of the bits then use SQL Server Management Studio to do a database backup of the 32bit SQL Server then restore this to your new 64bit server. NOTE: Make sure SQL and vCenter services are all stopped before doing the backup and the restore steps!
After the SQL restore on your new server reboot it and everything will come back to life just as it was only now with all 64bits!
Hope This Helps!
Bill Hilburn, Senior Systems Engineer
StoneAge, Inc.
Agreed, this is mainly a documentation problem; I finally found this described in the Upgrade Guide: you can (even more) simply install your new x64 O.S. and SQL Server, use the migration tool to export all settings from the old VC and do a manual backup/restore (or even detach/attach) of the database; then, when installing the new VC 4.1, you connect it to the new database, restore the exported settings... and the setup will automatically upgrade the DB.
Quite simple, actually... just very, very buried in the docs.
I've installed the following successfully, and documented it. There are some gotchas, so I have screenshots to help. It can be done!
The major gotchas are with the ODBC Driver nightmare.
Microsoft Server 2008 R2 x64
Microsoft SQL 2008 R2 x64
VMware vCenter 4.1
VMware vCenter Update Manager 4.1
VMware vCenter Converter 4.2
I hope this helps!
Joel Helgeson
Joel,
Why do you create a 64 bit and 32 bit ODBC data source?
VCP3 & VCP4 32846
VSP4
VTSP4
Joel,
Why do you create a 64 bit and 32 bit ODBC data source?
Because vCenter Server is a 64-bit software, while Update Manager is (still) a 32-bit one.
Thanks for the response, clears some things up in my head.
VCP3 & VCP4 32846
VSP4
VTSP4