Site icon Chris Colotti's Blog

How To: Upgrade VMware vCloud End to End

Chris Colotti

Now that vCloud Director 1.5 has been released I wanted to let folks know about the upgrade process that I happened to try out in my lab for the entire stack.  This is meant to be only a high level overview, but covers all the major components of vCloud NOT just vCloud Director.  More detailed steps might be forthcoming however those were developed for internal use at this point in time.  That being said you can use the high level steps below to understand what order things should be done in.  It is fair to say that you can do things out of order, but you might have some issues on the vShield side.  I will add some screen shots later, but for the sake of time I wanted to get this out there.  It is important to note that VMware has upgrade guides for each of the products and those should still be used.

References:

Chapter 3 of the vCD install guide.
The vSphere 5 upgrade guide.
The upgrade section of the Chargeback release notes.

All of this is the official documentation released with each product as it is part of every VMware product release

Other Known Items I found in my lab in addition to what is listed in the Release Notes:

Step #1 – Upgrade vCloud Director Cell(s)

This step will might require the use of the Cell Management Tool in order to quiesce the cells properly.  If you are using a load balancer there is instructions on upgrading the cells by creating separate load balancer pools.  However it is important to note from 1.0.1 to 1.5 there is a database upgrade that will be run from at least one cell, but you will need to ensure all cells are shut down before updating the database.  You can upgrade the binaries on all cells, but only issue the database upgrade from one.  You can time this as you see fit to minimize downtime, but some there will be a period of outage until one cell is brought back up on the new database tables.  You should also be able to see that the ESX hosts are still connected and available or “Prepared”.

If you are using NFS for multiple cells you will also note the directory structures changed to /opt/vmware/vcloud-director, so be sure to update your FSTAB mount to the new directory.  The old one will still be there but not a good idea to leave the old stuff behind.  For this reason I also did the reboot of the cell to re-map the mount point.  If you elected to move your certificate store you will need to re-run the config script to pick up the new location and as always keep your response.properties files.  Then you could clean up the old directories that were left behind.

Step #2 – Upgrade vShield Manager

In this previous post I addressed the fact you want to use the .TAR files to upgrade the vShield Manager.  This is absolutely the case and the last thing you want to do is remove your vShield Manager Virtual Machine.  However once upgraded you will notice there is an entirely new security model.  After upgrading the vShield Manager it will no longer be connected to vCenter.  You will need to use a service account to connect it back to vCenter and assign this user as an “Enterprise Administrator” in vShield Manager.  After you have ensured the vShield Manager is reconnected with the proper service account, you must also update the vCloud Director connection under vCenter properties to also use this account to talk to vShield Manager.  Previously most customer’s used “Admin” or other local account.  In my testing I always used service accounts but new local accounts may work.  I simply have not tried it yet in my lab.

Step #3 – Upgrade vShield Edge Devices

At this point you can choose to upgrade all the vShield Edge devices you have deployed.  However, per the Release Notes, you should wait at least 5 minutes before resetting so the vShield Manager can notify vCloud Director it has been updated.  You may want to ensure vCloud Director and vShield Manager are all working properly first by deploying a new NAT routed network and seeing that the right accounts are being used in vCenter and things are deployed properly.  This step is actually very easy and requires simply “Resetting” the NAT routed networks.  You will see a new vShield Edge get deployed with .updated in the name.  Eventually the old Virtual Machine will go away and the new one will be renamed to look like the original.  I have seen a small network connectivity loss to the vApps, but nothing significant.

Step #4 – Upgrade vCenter Chargeback to 1.6.2

This is the easiest of all the steps as the change to 1.6.2 is needed in order to support vCloud Director 1.5’s new database tables.  There is some other items in the release notes to take into consideration about what features like VPN Chargeback can and cannot track.  I did also learn that Chargeback 1.6.2 is not backward compatible with vCloud 1.0.1 or 1.0 as indicated in the release notes.  This is due to the database changes with vCloud Director 1.5.  So no matter when you update this component, you may want to stop the services until vCloud DIrector and the Database are upgraded.  Conversely you can reverse Step #1 and Step #2 if you choose.  Either way it is a rock and a hard-place in regard to Chargeback Data compatibility with the old and new vCloud Director Databases.

Step #5 – Upgrade vSphere vCenter

Now you can either decide to remain on vCenter 4.1 or move to vSphere 5 for all the added goodies.  This should be a standard update to vCenter as you have done in the past.  Nothing I found in my lab changed, however if vCloud Director is only configured for one vCenter, you will lose the ability to deploy and manage Virtual Machines during this portion of the upgrade.

Step #6 – Upgrade vSphere ESXi

Thank heaven for Update Manager right?  You can use Update Manager to update all your ESXi hosts, but be sure to read any warning messages that may popup on things like agents as third party agents may need to be removed.  Once the host is upgraded it should still show in vCloud Director as “Prepared” with the new vCloud DIrector Agent.  I did not have to un-prepare and re-prepare in my Lab.  You may also need to remove third party agents manually before upgrading in case Update Manager is not able to remove them properly for you.

Step #7 – Upgrade vSwitches, VMFS, Tools, Virtual Hardware, and finally set vCloud to use Hardware Version 8

At this point there is more tedious effort involved but this could be done by multiple people.  To take advantage of some new features you need vCloud Director to be set for a maximum hard version of 8.  However, you don’t want to do that until you have upgraded ALL the ESX hosts in a provider vDC, AND updated the tools and hardware on the currently deployed vApps.  In turn do not forget to update you’re vApp Templates.  This is SOP as with other major ESX upgrades.  You will want to upgrade the tools first, then update the “Virtual Hardware” to maintain IP addresses, but also remember vCloud Director sets the IP’s from pools for you so this should not be as big a deal as in standard vSphere.  Also upgrade you VMFS to version 5 as well as your vNetwork Distributed Switches.  This final change will be setting vCloud Director to use the highest hardware version available as 8.

This should get you going, and I will add some screen shots from my lab as I will run through this one last time with the final GA bits of all products, but I suspect it will go smoothly.  The real thing to remember is the bullets at the beginning about Database migrations and ESX compatibility.  As Always be sure to know what is actually SUPPORTED with vCloud Director 1.5, and that article I will also be updating.

 

Exit mobile version