Upgrading to vSphere Part 1: Installing vCenter
Last week I started our migration from VMWare’s VI3 to vSphere. There are many improvements to the load balancing capabilities as well as the management capabilities. The storage engine has been greatly improved as well. Storage vMotion is available in the GUI without a plugin and thin provisioning is finally available, which is a huge boon and reason enough to make the move on its own. Most of this process can be completed with no downtime for the virtual machines.
Environment
Our environment is fairly small in terms of number of hosts, but we have most of the components in place, which makes for a very nice upgrade experience.
- A VirtualCenter Server v2.5 (primary data center)
- Two host machines v3.5 (primary data center)
- Two host machines v3.0 (disaster recovery data center)
Procedure
The first thing that needs to happen during the migration is upgrading the VirtualCenter server. vCenter 4 is very capable of managing legacy products, but it’s a good idea to take a look at the compatibility matrices just to be safe.
Migration Strategy
The hardware that our current VirtualCenter Server was running on was less than adequate for running vCenter 4. So, I went ahead and built a new server to host vCenter. This had an added bonus of a very easy rollback plan if anything went wrong. All I would have to do is restore the database and boot up the old server. VMWare has an article that outlines part of this process at http://kb.vmware.com/kb/5850444
Installation
To use the existing VirtualCenter database, a system DSN needs to be created to point to the existing database. Enter in the user credentials and set the default database to “VCDB” (or whatever your VirtualCenter database is called) and the rest of the settings should be fine at the defaults. It’s important to note that the VirtualCenter service should be stopped and disabled on the original server before proceeding from here. Bad things can happen if you have two servers trying to access that database.
After creating the DSN, I began installing vCenter4. I was greeted with an error saying: “Please make sure SQL Server Agent service is running on the database server.” This ended up being an issue with some maintenance jobs that I had set up when migrating the database. Renaming them resolved the issue.
The next thing to keep in mind is that VirtualCenter and vCenter make use of SSL certificates. These needed to be copied from the old VirtualCenter server. By default, they are located at %AllUsersProfile%\Application Data\VMWare\VMWare VirtualCenter\SSL. I copied the entire SSL folder onto the new server and vCenter found it without issue.
Post-install Configuration
From here on out, I let the installer do the rest of the work. In about 5 minutes I had a working vCenter server set up. At this point I had to connect the hosts to the new server. Before the ESX hosts can be connected, however, they need to be licensed. vCenter handles this by allowing you to specify the IP address of an external licensing server for legacy hosts. Adding the IP address the old VirtualCenter server will take care of this for the time being.
Each ESX host remembers the IP address of the VirtualCenter server that manages it to prevent conflicts. Right-clicking the server and selecting connect will make vCenter communicate with the hosts and override that information. It will then connect the the new vCenter server to the host.
I had a little trouble with our remote ESX hosts. It’s important that the /tmp/vmware-root directory exists on the target ESX host. If that’s not there, the vCenter server is unable to transfer binaries that are required to set up the connection. The folder can be created by the root user; default permissions should be fine. One of our servers was a little more difficult than the other and still would not connect after creating the temp directory. Restarting the vmware-mgmt service resolved this.
Still to come…
vCenter 4 is now managing our ESX 3 and ESX 3.5 hosts. In the next post I’ll walk through the process of upgrading the host machines and the virtual machines.