The upgrade to VC2.5 on a production VC2.0 server went cleanly, with a simple installation wizard pulling the strings. At the end of the process, the VC2.5 server was running, and using the new VIC2.5 client, I could log in and view the production farm—except there wasn't one. The upgrade process didn't migrate the previous database to the new installation, and I had to redefine the clusters, hosts, and even templates that existed on the farm. In a small environment this is simple. In a large environment, this could be a big problem. This gotcha, and many others in this upgrade, can be dodged by careful planning and research on the process, not to mention a thorough reading of the release notes. But VMware could have done more to smooth the way. I really would have liked to see a straightforward database migration process with validity checking during the upgrade to minimize problems in this area.

Following the upgrade, and the subsequent redefinition of some farm parameters, VC2.5 was running against an ESX 3.0 farm without issue. Next step: Upgrade the hosts.

The easiest way to upgrade an ESX host to ESX 3.5 is to download the ESX upgrade package from VMware. Customers with an existing support agreement can download the updates for free, and existing 3.0 licenses should work with 3.5 hosts. There are other methods of performing this upgrade, but using the upgrade packages is by far the simplest.

The ESX 3.5 upgrade package is essentially an archive containing RPM packages and some supporting scripts. Using SCP, I moved this archive to a folder on the central farm datastore, and began updating each host from that package. It's a relatively time-consuming process but still surprisingly simple. I first placed each host in Maintenance Mode, which forces the active VMs on that host to VMotion to other hosts in the farm, then ran esxupdate on that host, specifying the directory containing the ESX 3.5 upgrade packages. A few minutes and dozens of RPM updates later, the host was upgraded. I then rebooted the host and took it out of Maintenance Mode in VirtualCenter. It was then just a normal host in the farm, and VMs began to migrate to it in accordance with the DRS (Distributed Resource Scheduler) rules present on the farm. The whole process took about 15 to 20 minutes per host, with most of that time spent waiting for the host to enter Maintenance Mode, and waiting for the host to come back up following the reboot. After the last host was done, the whole farm was up to ESX 3.5 with no ill effects.