Thursday, February 3, 2011

Migrating/upgrading a 32bit vCenter 4.0 installation to a 64bit 4.1 installation

With the coming of vSphere 4.1, vCenter now has a prerequisite of needing a 64bit Windows operating system. Many customers that upgraded from ESX3.5 to vSphere were using a 32bit Windows installation, but also many vSphere installations were built using 32bit Windows. vCenter 4.0 even needed 32bit DSN's so it appeared it was easier to just install vCenter using a 32bit installation. To make things worse, many vCenter implementations have SQL Server installed on the same server as vCenter itself. This article will be about the upgrade process of upgrading windows 2003 32bit with SQL 2005 32 bit to a 64bit environment, and migrating the data.

During testing, this upgrade was quite difficult because of little snags, so it is very wise to do a dry run of this using a P2V’d system and testing the upgrade thoroughly before you do this on a live system. You wouldn't want to reinstall your OS and find out your migration data is useless.

-          Windows 2003/8/8R2 x64 Standard
-          SQL Server 2005/8 x64 Standard (2008R2 is NOT supported yet)
-          VMWare vSphere 4.1 vCenter installation media
-          External source, such as an external harddisk or fileshare.

Basic steps
  1. Make sure all data is safely backed up, and you have all the information off of your 32bit installation
  2. Stop virtual center service, update manager service
  3. Run the backup.bat from VMWare's datamigration tool
  4. Copy the datamigration complete with data to an external source
  5. Stop SQL Server service and SQL Server agent, copy the ESX and Update Manager database to the external source
  6. Wipe server and install server with 64 bit OS, using the same name and IP as the previous one
  7. Install Microsoft SQL Server
  8. Copy vCenter and Updatemanager database to the newly installed server
  9. Set permissions on the databases, and on msdb
  10. Set compatibility mode of the db to SQL 2005 if your SQL Server came from SQL 2000.
  11. Create the ODBC links
  12. Copy the datamigration directory back to the server
  13. Make sure you have the vCenter installation media on dvd or on the server in a directory as well
  14. Run install.bat from the datamigration directory
  15. Answer the installation questions from the installer
Detailed Steps

So you want to migrate a 32bit system to a 64bit system. This means you will be doing a complete re-installation of the operating system. I will assume only the database (in my tests SQL2005) is installed and standard users have been created, and no extra software has been installed.

Once the first VMWare services are stopped, management through vCenter will be impossible, but the VM’s will keep on running. Services like HA and DRS will be unavailable then, but VM’s should not notice anything of this. 

Collect information and backup the system
Note the following:
-    IP address(es)/subnetmask(s)
-    Hostname
-    Workgroup (if the machine is part of a domain, take note of that as well)
-    Routes
-    Host file (c:\windows\system32\drivers\etc)
-    Usernames (and passwords, if you have them)
-    Possible created groups

For SQL look at the following things:
-    Which databases are configured
-    Where are the databases stored
-    Which Service Pack is the database currently
-    Any extra settings made in SQL, such as maintenance and backup plans.
-    The ODBC DSN’s used to connect the database to the Virtual Center.

Of course, if you have installed extra software, make sure you have copied any settings and data from that application. Finally, make sure you have a working backup, or pull one of the disks of the raid 1 set. This will ensure you can easily go back to the 32bit environment.

Stop vCenter services
In computer management, stop the following services
-    VMware VirtualCenter Server
-    VMware VirtualCenter Management Webservices (will be stopped along with the first service)
-    VMware Update Manager Service

Fortunately, VMWare has made a datamigration tool to help with the migration from 32bit to 64 bit. On the installation media, there is a directory called datamigration. In that directory is a zipfile. Extract that zipfile to your harddisk, or to the external harddisk, as this extracted directory will also hold the data from the migration. I have tried to run the tool from a network share, but it wouldn't work properly, so my advice is to not do that.

Open a command prompt, change to the datamigration directory and type “backup.bat”. The script will prompt you if the data needs to be backed up. Type Y and press enter to continue.
New files and directories will be created i
n the datamigration directory. The “data” directory will hold the configuration data from vCenter, Update Manager and vCenter Orchestrator (directories will be created vc, vum and vco). There will also be a "log" directory to show the results of the migration.

When the backup is done, check the vc and vum directories for data (and if vco has been used, check if there is data there too). The vc directory should have a vc_ssl with keys in them, and also a vc_data file, which is kind of small (in my test environment of 4 servers, it was 24kb).  The vum will have data there too, as well as update files downloaded from the VMWare site. This will be quite big (several GB).

Copy the data
Copy the entire datamigration directory to the external source (if you haven’t extracted it to the external source beforehand).

Stop SQL services and copy the databases
Stop the following services for SQL:
-    SQL Server
-    SQL Server Agent
You can now copy the MDF and LDF files belonging to vCenter and the Update Manager from the server to the external source. To speed up the copy, you could shrink the database before you copy the files. My test environment database shrank from 2GB to 200MB.

“Nuke and repave”
Reinstall the server with the 64bit operating system, using the same name and same IP information.  There will be issues with vCenter if other IP information is used. Patch the system as you would normally patch a system. Create routes, possible hosts file entries, users and groups. Re-install a SQL 64bit edition, and install the same service pack as the 32bit edition. You can go from SQL 2005 to SQL 2008 without needing extra configuration. I like to configure SQL so that it installs the databases to another disk from the SQL installation.

Copy databases back and configure SQL
Copy the MDF and LDF to the newly installed server, in the directory where the other databases are stored.  In the SQL Server Management Studio, attach the databases.

Make sure vCenter user has been assigned “db_owner” for both the vCenter and Update Manager database, as well as the MSDB database. This is necessary to be able to upgrade the database during the vCenter installation.

Another important thing is that the compatibility level be set to SQL 2005 (90). If the SQL instance you came from used to be SQL 2000 (e.g. when you have an old vCenter that has been upgraded from VI3) it is likely that the compatibility level is set to SQL 2000. Not setting this properly will make the upgrade fail!  

Configure other settings as needed, such as re-implement maintenance plans, and set the recovery model to Simple again. Do the same for the Update manager database if you use that.

Recreate ODBC connections
To recreate the database connections you will need DSN’s. Go to the Data Sources (ODBC) tool in Control Panel -> Administrative Tools and add a system DSN for the vCenter database and Update Manager. If you plan to migrate update manager as well, you need to use a 32 bit DSN for that. Run c:\windows\syswow64\odbcad32.exe to get the 32 bit version, and add a system DSN there.

With me so far? Good, then the fun part can start: Getting vCenter back up and running.

Installation/Upgrade of vCenter server 4.1
Copy the datamigration directory back to the server, and for speed sake, copy/extract the vCenter installation directory to the local harddrive. In any case you need to have this available when the datamigration installer is started.
Open a command prompt and change to the datamigration directory. If you are using Windows 2008, open a command prompt by "run as administrator". Type “install” to start. The installer script will check to see if the vCenter data is available, and tell you if all data is available or not. If it is available, it will use these settings during installation. It will ask for the directory of the installation media (e.g. D:\vim410).
After this it immediately checks for the Upgrade Manager upgrade data and ask for the installation media again. This is the same directory as before.

As a sidenote: I have had three or four attempts of testing this in a test environment, and a the first times the installer said there was no upgrade data available. I needed to run the backup script on the source again. That is why it is important to check for the existence of files during the backup and to test this upgrade before you try this on a live environment.

After the question for the Upgrade Manager has started, the installer for vCenter 4.1 will start.  Select the vCenter DSN and answer “yes” to the question if the database should be upgraded. At one moment, the question will come if the host agents can be upgraded automatically. I answer no.

In vCenter the ESX hosts will be in a disconnected state, but the VM information will be seen, and you should be able to see the performance data of the VM’s. I select no, because you can still fall back to the old installation until the complete installation finishes (remember that disk you took from the raid 1 set, or the backup of the previous installation? The ESX hosts can then still be managed by vCenter 4).

After the installation, the installation for Upgrade Manager will immediately start. Follow the instructions as they appear on screen.
Install the updated Virtual Infrastructure Client from the vpx directory in the installation media (vi-client.exe) and then connect to the vCenter. The hosts are in a disconnected state, but you can simply rightclick the hosts, and click "Connect". The agent will update, and HA will be re-enabled.

This should be all you need to complete a successful migration.

Note to self: Make some screenshots next time...

    No comments:

    Post a Comment