Upgrading to vSphere Part 2: Hosts and VMs
In my last post I described my experience with upgrading from VirtualCenter 2.5 to vCenter4. Here I’ll be describing the process of upgrading the host machines via a couple of different methods as well as my process for getting the VMs upgraded to the latest verision of VMware’s virtual hardware.
Upgrading Hosts
VMWare has made it very easy to upgrade hosts to ESX 4. I made use of two remote upgrade options in my migration:
- vCenter Update Manager
- A centralized update management system which can handle anything from security updates to full ESX upgrades
- The Host Update Utility
- A standalone application built into the new vSphere client
vCenter Update Manager
For the local host machines, I made use of vCenter’s update manager. This is an add-on for vCenter and it requires its own database, but I highly recommend using it. Its end functionality is similar to any built-in software update mechanism, but its flexibility is what makes it really impressive. For information on installing, please see the administration guide.
Update Manager works on the idea of a “baseline”: a set of minimum requirements that a target needs to meet to be considered compliant. Baselines can be applied at any level in the vCenter hierarchy. To handle the upgrade of our host machines, I created a baseline for ESX hosts specifying that they should be at level 4.0. I then applied this baseline at the datacenter level in both sites. In some cases it may be more apt to apply it at the cluster level, but we have no necessity for legacy hosts in our case.
Once the baseline was applied, I selected the host I wished to update and clicked the update manager tab. I could see, as expected, that it was not compliant with the upgrade baseline applied to it. In a DRS cluster, one should be able to click the remediate button and let vCenter do all of the work to migrate VMs off and put the host in maintenance mode prior to the upgrade. This requires that you keep a pretty clean environment, however.
In our case, we had some hosts that were unable to vMotion either due to snapshots or mapped drives, so I had to take care of things manually. As soon as the host was in maintenance mode, however, choosing remediate rebooted the host and performed the upgrade all on its own within about 20 minutes or so. The progress bar was fairly accurate at most points of the upgrade and once the host was back up, I could see that it was compliant with the baseline.
The Host Update Utility
One major concern in my case was a couple of hosts sitting on the other side of a slow (3mbps) WAN link. I’m sure you’ll agree that most IT tasks are at their best when they go unnoticed. Well, taking up a huge chunk of a site’s bandwidth while I transferred an ISO multiple times would certainly not win me any gold stars.
VMWare’s Update Manger is capable of staging updates on the target for later install, but this only works on hosts that are at 4.0 or above. It would also require moving the ISO over the WAN multiple times, because the updates are staged to the host rather than another vCenter or Update Manager server. This made the Host Update Utility a much more interesting option.
Fortunately, there’s already data replication going on between the main site and the remote one for DR purposes. I was able to mount a snapshot of one of our DR volumes and copy the ISO onto a file server in that site. Launching the host update utility for the first time, I received a prompt to download patches from VMWare. The servers then needed to be added by hostname from the file menu. Once they’re added, the host update utility will do a quick scan to find out what version they’re at. If it’s in an upgradable state, the “Upgrade Host” button will initiate the upgrade.
Overall the procedure from this point on is very similar to the update manager service. The one notable exception is that there is a lot less feedback regarding the status of the host. There were a few times where I was wondering if the hosts were stalled, but eventually the progress bar jumped forward and I could see that things were still working. For this reason, I definitely recommend using the update manager service where possible.
Upgrading VMs
To take full advantage of the new functionality in vSphere 4, the VMs, themselves, must be upgraded. ESX 3.x operated on virtual hardware version 4. vSphere uses version 7, which has a number of notable improvements in storage, networking, and hotswap capability. It’s important to note that there are a few disappointments with the new networking and storage modules, but overall it’s a large step forward. There is a useful article at boche.net that talks about memory and CPU hotplug.
Upgrading the VMs is a two step process requiring at least 2 reboots (my process includes 3). First, the VMWare tools installation must be upgraded in the guest operating system. This may be done either from the vSphere client or from within the guest OS by opening the VMWare tools console. In my case, I chose to upgrade from within the guest so I was keeping an eye on every step of the process. This may not be viable for anyone with a large number of VMs to update. Upgrading the VMWare tools will require a reboot.
Secondly, the virtual hardware needs to be upgraded. The virtual machine needs to be powered down for this step. It’s a simple matter of right-clicking the virtual machine and selecting “Upgrade virtual hardware”. A message will pop up notifying you that this is a one-way process and once it’s finished, your upgraded VM will not work on older versions of ESX. Keep this in mind if you have any legacy hosts staying in your environment.
The next time the guest OS boots, it will detect the new hardware and configure it. For Windows VMs, this will require another reboot. I haven’t, yet, tested the process on a Linux VM. Once the guest OS is finished rebooting, the upgrade process is complete.