VMware’s Update Manager (included with vCenter 5 download) has a nice, new feature for help in upgrading your hosts from ESXi 4.1 U1 to ESXi 5. The feature, Figure 1, is found in the Admin View and is simply called “ESXi Images”. It allows you to upload ESXi images in to the Upgrade Manager Repository to be added to Host Upgrade Baselines.
Figures 2, 3, and 4 show the process of selecting an ESXi image, uploading it, and then creating a host upgrade baseline for the uploaded image.
Figure 5 shows the newly created ESXi 5 image, it’s corresponding baseline name, and the software packages included in the upgrade.
Figures 6 and 7 should be familiar to you if you’ve used Update Manager in the past. Figure 6 shows the attachment of the baseline to the desired remediation object (in this instance, I’ve attached it at the datacenter level). Figure 7 shows the compliance details after scanning both ESXi 4.1 U1 hosts in my datacenter.
I found it interesting that the hosts were reported as being incompatible. The first host, 192.168.0.147, is ESXi 4.1 U1 build 348481. The second host is fully remediated with the latest ESXi 4.1 patches, ESXi410-201104001 and ESXi410-201107001, making it build 433742. Figure 8 shows the details of the incompatibility; OEM drivers that shipped inbox with ESXi 4.1 U1. Even though it’s marked as incompatible, there’s a checkbox during host upgrade remediation that allows Update Manager to remove incompatible software as part of the upgrade process.
Figure 9 shows the process of selecting a host and the desired baseline.
Figure 10 is the EULA acceptance screen.
Figure 11 shows the feature I mentioned previously; removing non-compatible 3rd party software modules from the upgrade process so the upgrade can be completed sucessfully. It also advises that doing so could have functional implications and recommends that a custom image be built using the ESXi Image Builder CLI in order to successfully remediate an image that requires 3rd party modules. In my case, I didn’t need the software modules that were to be removed (I was using ESXi on VMware Workstation), but nevertheless, this is very critical point to the upgrade process. If you were to not check the box that allows incompatible software removal, the upgrade will not succeed — meaning you’ll have a dead/broken host. If you were to remove the software and it has a functional impact, the upgrade might technically succeed, but there’s a possibility that you still might have a dead/broken host as a result.
PLEASE test thoroughly before running an ESXi 5 upgrade in a production or similarly important VMware environment.
Figures 12, 13, and 14 show the ESXi 5 installer booting, the caching of required files necessary to the upgrade, and the screen showing the upgrade was completed.
After the host completes remediation and reboots, it automatically reconnects to vCenter, and the root password is preserved during the upgrade as well. Overall, I thought the upgrade process was straightforward and a little bit cool. I hadn’t tested the upgrade of a host that was connected to Active Directory, but I would imagine that it rejoins the domain as well. Once again, if you do plan on upgrading your ESXi 4.1 hosts in place – test, test, test!
Yikes! That’s a scary update process. I did mine like this: http://public.madeinengland.co.nz/how-to-migrate-from-vsphere-4-to-vsphere-5/
Lars Sørensen says
Thanks – got stuck in the process because of the yellow incompatible sign. Vmware could certainly optimize the GUI a bit:
– More help text when clicking on the “incompatible” symbol as the text does nothing for anyone.
– Check in advance if the host is in a cluster. I put my host in maintenance mode and still had to see a error text like “Cannot remediate host xxx because it is part of a HA admission control enabled cluster”. Vmware apparently didnt see any benefit of checking this before i clicked Finish in the remediate wizard.
I believe if you get down to the actual host level inside VUM, it’ll give more detail as to why it is incompatible. Most of the time it is probably because you have third-party VIBs installed (and who doesn’t?). You can check the box to remove those on the upgrade (assuming you’ve got the new ones in an extension baseline of course).
Thanks for the write up. This worked awesome.