Posts Tagged ‘4.0 to 4.1’

Sep 14

With the recent(ish) release of vSphere 4.1 comes the task of upgrading ESX/ESXi hosts to this new build, fortunately, with some of the tools available from VMware (VMware vCenter Update Manager) the host upgrade process is fairly simple, and takes approximately half an hour per host (plus some time afterwards for testing).

The latest version of vCenter however is slightly more difficult for some people… The latest edition requires a 64-bit OS, and more RAM than the previous version. Now RAM is easy, but you can’t “upgrade” a 32-bit OS to a 64-bit OS which can make migrating it slightly difficult!

I’ve got this arduous task to come but here’s my proposed plan…

  1. Check your physical host (if using one) complies with the HCL for vcenter: http://www.vmware.com/resources/compatibility/
  2. Use your favourite VM conversion tool to get a copy of your current vCenter server as a virtual machine (if it’s physical that is).
  3. Take a backup of your vCenter (and Update Manager if applicable) databases. Also backup your vCenter server’s SSL certificate information as you’ll need this later if you have your own certificates.
  4. Shut down the vCenter physical host and then boot the VM version.
  5. Check that the VM version is working correctly, and then power it down.
  6. Rebuild your vCenter server with a 64-bit OS such as MS Windows Server 2008 R2. If you need to give it the same name in Active Directory then reset the computer account first in AD so that this machine can join in its place.
  7. Create an ODBC connection to the vCenter DB on your DB server (or install it locally and restore the DB). If you were previously using Update Manager, then create the ODBC connector or restore the DB for this too.
  8. Install vCenter 4.1, as well as vCenter Converter, and vCenter Update Manager.
  9. Copy in the SSL Certificates you backed up earlier.
  10. Open the vCenter client and install the plug-ins for Update Manager and the Converter.
  11. Check that all the hosts can be accessed correctly, if not, right-click the host, choose “Connect” and then follow the wizard.
  12. Once that’s done, check through all your client settings, and the settings for Update Manager to check all is normal.

That should be about it, as I said, I’ll be performing this task shortly (about mid September) so I’ll update this entry if anything does need changing! Next it’s time to upgrade the hosts…..

UPDATE:

Ok, so this wasn’t as easy as I first thought it would be… VUM was a pain, in fact, I ended up creating a new database and scrapping the old one (not too much hassle for me though when my VUM server is sat behind a 1Gbps internet connection…). So, here’s what I did and how I did it, starting with my previous config:

I had a vCenter 4.0U1 server running on Server 2003 Standard x86 with 4GB of RAM. There was also a server running server 2008 R1 x64 running SQL 2005 for the vCenter and VUM databases. All sat on a 1Gbps network.

The perceived final result would be a vCenter server running version 4.1 with Windows Server 2008 R2 Standard x64, connected to the same, unaltered, SQL server as before. This sounded really simple!

So, here are the steps I took to rebuild the vCenter server:

  1. I started by using VMware Converter to convert the vCenter host to a VM so that I knew, should all else fail, I’d have a backup copy.
  2. I then backed up the SQL databases so that I knew they were also protected.
  3. I shut down the vCenter server and booted the VM copy to check that this still worked ok.
  4. Once I was happy that this was alright, I shut down the VM and booted the physical server with the 2008 DVD.
  5. Once Windows was installed I did all the usual bits: Windows Updates, teaming the NICs etc. I then reset the computer account in AD and joined the server to the domain.
  6. I then set about recreating the ODBC connections. This became a little bit of a task… vCenter still requires a 32-bit DSN and having not needed this before, setting up was a challenge… Anyway, you need to run odbcad32.exe rather than the ODBC tool under Administrative Tools. Simply running this from the Run prompt wasn’t working though, so I ended up running it from c:windowssyswow64odbcad32.exe.
  7. I then installed vCenter and the vSphere client, which worked a charm after fixing the ODBC connector. At this point, I wasn’t installing Converter, or Update Manager, I wanted to deal with vCenter first.
  8. If you have your own certificates for vCenter this is when you copy them back in… If you don’t, just reconnect the hosts by right clicking, choosing “Connect” and running through the wizard. Easy. Well, unless (like me) you have a host that won’t join the HA cluster… more on that in another article!
  9. OK, so by this point you can start testing that vCenter is working OK, so I started performing some vMotion operations, and checking through the console that configurations could be changed etc. Once happy that all was OK, I moved on…
  10. So, now I installed Update Manager and VMware Converter.
  11. After this, I logged back into the vSphere client and isntalled the required plug-ins, then restarted the vSphere client.
  12. This is when the problems struck…. VUM wouldn’t work correctly. I couldn’t scan machines, or hosts for updates. I then noticed that the service wasn’t running in an account that had access to the SQL database… so I changed this, still no luck! In the end, I gave up, created a blank database on SQL, altered the ODBC connection to point to this DB and job done, Update Manager worked again. So, then I kicked off a patch definition download (again, not a problem when you’re sat behind a massive internet connection).

In essence, the migration had gone as planned, the server had been rebuilt, and was using the old database like I was hoping it would. Yes, I had some issues with a host not joining HA correctly, and yes I had to rebuild the VUM database (which let’s face it, isn’t the end of the world unless you have a lot of custom baselines). So, where from here? Oh yes… upgrading the hosts… and of course VMware Tools on each and every VM… that’s a time consuming task when you have over 200 VM’s in a single cluster, especially when there’s only 4 ESX hosts!

So… you can probably guess what will be coming up soon on this blog… yep… Upgrading ESX or ESX(i) 4.0 to 4.1…


%d bloggers like this: