In Part II of this article, we went through the process of upgrading a VirtualCenter 2.5 server to vCenter 4.  In this third and final part, we’ll talk about upgrading the hosts to ESX 4 and wrap up the upgrade process.  Let’s get to it then:

ESX Host upgrades:

  • First of all, make sure IP and networking configuration for all hosts is documented and available.  For most information, a screenshot of the “Networking” screen should be enough.
  • Confirm that the license service on VirtualCenter (old) server is running and accessible.
  • Check if all applications within VMs are compatible with and supported on vSphere 4/ESX 4.  Pay particular attention to software/utilities that access storage directly e.g. NetApp SnapDrive etc.  If a newer version is required to maintain functionality – do all process testing, before proceeding.
  • If all is good, migrate running VMs to some other host(s) in your cluster.
  • Once done, switch the host to “Maintenance Mode”, move it out of the cluster, “Disconnect” the host from the environment and finally, “Remove” it from the virtual environment.  This is done to “cleanly” remove the ESX host from service.
  • Remember that removing a host from the cluster might also cause a violation of HA availability constraints.  Make sure you have taken this into account and that the service is not at risk as a result.  For example, if you have fewer hosts than are required, your HA settings might prevent new VMs from powering-up.
  • Shutdown the host and disconnect attached storage by taking out all SAN storage connectivity from the host (this only applies if you are installing ESX on local storage).  You don’t need SAN storage if the install needs to be local but disconnecting storage, protects the data on the SAN from accidental deletion.  Chances are that the host is already part of a LUN access group so all relevant storage will be visible to the installer.  It pays to be safe – better safe than sorry!
  • The upgrade process is not too different from the previous versions but their are some improvements and therefore, minor changes.   As you are upgrading, you’ll be able to deal with the changes easily.  Make the minor changes to your existing process.  The new installer allows you to put serial number for the host in but don’t do that if you have licensing controlled by vCenter.  Your 60-day grace period should OK in the meantime.
  • My partitioning scheme is here as a sample (you might wish to have something different):

/              Ext3       20 GB

(none)    Swap     1.6 GB

/var        Ext3        15 GB

/opt        Ext3        10 GB

I allow more room on / as that’s one partition that shouldn’t go full – for obvious reasons.  Swap size is based on a service console memory configuration of 800MB (recommended).  /var is to protect / space from getting consumed by the likes of /var/log etc. and /opt is there to provide a place for vendor applications, as at lot of them tend to use that path by default.

  • The rest is pretty straight-forward and I am sure you can tweak your existing processes to fit the new recipe.  If you detached SAN storage before the install, a good time to reconnect would be while the server is rebooting after install.
  • Install hardware monitoring software or SAN utilities, if required.
  • Do a “Rescan” and make sure all storage is available in the same way as before.
  • Reconfigure “Networking” to match previous configuration.
  • Add the host back into the cluster.  The process is almost identical to VI 3.5.  If you’ve already added license keys to vSphere then you should be able to assign the license while adding the host to the cluster.
  • Hopefully, the host will be added without issues, especially if networking was pre-configured to match previous configuration.  If it still has a red blob after addition then running “Reconfigure for HA…” once more helps greatly.  This also works if you’ve added a network adapter to the service console vSwitch but the interface is still complaining “There is no Management Network Redundancy on cluster x”.
  • The ESX server should now be ready to host VMs again.  Migrate VMs from another host to this one and repeat the process mentioned above for all hosts.
  • All VMs coming back to an upgraded ESX 4 Update 1 host will show VMware Tools to be out-of-date.  You can upgrade them together “automatically” in the same way as in VI 3.5.  Alternatively, if you want more control, do them individually at appropriate times.  VMware Tools upgrade requires a reboot so you might wish to agree reboot times with appropriate stakeholders.
  • With the upgrade, comes the option of upgrading virtual hardware.  As you would expect, it allows more resources for VMs and some new features rely on upgraded virtual hardware.  However, don’t upgrade virtual hardware until you have upgraded VMware Tools first.  Also, consider this change to be equivalent to changing a motherboard on a physical machine.  You might have to think about drivers for the OS you’re running inside that VM and it will definitely require a couple of reboots.  So, think carefully before doing it and only after confirming DR provision for the VMs in question.  You might also decide not to do it for existing machines, unless really required – or do it over a period of time as it is not urgent or necessary.
  • If you are using SAN software that requires direct access to SAN from within the VM e.g. NetApp SnapDrive and you’ve tested the upgrade process, do the upgrade as soon as the machine is moved back to an upgraded host.

 Wrapping Up:

  • Once all ESX hosts have been upgraded and VMs back to where they should be, it’s time to wrap up the process.  Go to “Home – Licensing” on the vCenter server and expand the ESX 3 licenses area.  If all hosts are upgraded to ESX 4 with licensing updated, this section should show that 0 licenses are allocated.  This is, of course, assuming that you did a like-for-like upgrade for all ESX hosts.
  • Having all VI 3.5 licenses released and vSphere licenses consumed, gives you the confidence that everything has been upgraded correctly.  If true, backup the lic file from old VirtualCenter server (just in case), remove its reference from the new vCenter server licensing configuration (the entry “27000@<old VirtualCenter server>”) , stop and disable the license service on the old VirtualCenter server and shut the server down for good.  I generally remove it from inventory but don’t delete it for a couple of weeks – being the careful person I am 🙂
  • Remove the old VirtualCenter server from any backup regimes and monitoring processes etc.
  • Configure any roles that are required on the new vCenter environment and test access.

That’s it!  You should have your whole environment upgraded to vSphere 4 Update 1 now.   Obviously, I am sure there will be steps that I’ve missed or not described in enough detail but hopefully, this will give you an overview of the whole process in the right sequence and will act as a “checklist” of things that you should consider before embarking on an upgrade.

Hope this helps!