In Part I of this article, we started with some points one should think about while preparing for the upgrade of a Virtual Infrastructure 3.5 environment to vSphere 4.  In this part, we’ll go through the process of upgrading the VirtualCenter server to vCenter 4 Update 1.

vCenter Install:

  • Create a VM for the new vCenter server.  Suggested spec (varies according to requirements): 2048 MB RAM, 2 vCPUs, Typical SQL server VM Hard Disk configuration for your environment.  Make sure your partition map has enough space to hold Windows 2008 + SQL 2008 + Applications (vCenter + Converter + Update Manager) in the appropriate partitions and still have some breathing space.  Think ahead – will the space be sufficient for the next few years – considering service packs and patching requirements, etc?
  • Install Windows 2008 Standard x64 using your normal processes.  Make sure it’s sufficiently “hardened” and IIS is “not” installed.  I enable RDP as well.  Powershell 2.0 should also be installed – to be used with PowerCLI later.  It’s also useful for general management and remoting etc.
  • Install SQL 2008 Standard x64 using your normal processes.  It might ask you to install .NET Framework as a prerequisite – which is OK.  Remember: What you really need is basic SQL database services so if you have a cut-down version of the install process, it should be fine.  I change every path to install files on a partition other than C: (You still end up with some common stuff on C: – still better than having everything dumped there).  You can do whatever suits your processes.
  • Create a temporary folder on the new server (called “vCenter server” hereinafter).  Go to the old VirtualCenter server (called “VirtualCenter server” hereinafter), fire up “SQL Server Management Studio” and make note of the database holding VirtualCenter data.  Make a full backup of this database.  Copy the resulting .bak file to the temporary folder on vCenter Server.
  • Also, copy the “SSL” folder from “%ALLUSERSPROFILE%Application DataVMwareVMware VirtualCenter” to the temporary folder on vCenter Server.
  • Fire up “SQL Server Management Studio” on vCenter Server and create a new database with the same name as your VirtualCenter database.  Restore the .bak file (transferred earlier to the temporary folder) on top of this new database, with “Overwrite the existing database (WITH REPLACE)” check box selected in “Options”.
  • Even though this is a x64 server, the ODBC connection still needs to be 32-bit.  To create that, double-click C:WindowsSysWOW64odbcad32.exe, select “System DSN” tab, select “SQL Server Native Client 10.0”.  Name the connection something appropriate (I call it “VMware vCenter”).  Make sure you select the correct SQL server from the drop-down list.  Change the default database to the one you just restored in the previous step.   In the end, test the settings to ensure that connection is successful.
  • Copy the “SSL” folder to “%ALLUSERSPROFILE%VMwareVMware VirtualCenter”.  Create the folder structure if not present.
  • In this scenario, both VirtualCenter and vCenter are running in a VM configuration so we need to connect directly to VirtualCenter server for the next few steps.  Make note of which ESX host is running VirtualCenter and vCenter servers.  Connect to VirtualCenter (either via RDP or console connection directly to the ESX hosting VirtualCenter) and stop and disable all VMware services, apart from “VMware License Server” service.  Please note: At this point, you will lose management/VMotion/DRS-related capabilities etc.  for your environment, although HA will remain operational and you can always connect directly to the ESX host, if required.  VM operations will also be unaffected.
  • Connect directly to the ESX server running vCenter server.  Connect the vCenter 4 Update 1 ISO to the VM and let the installer come up.  Select “vCenter Server” from the installer menu.  Select the appropriate language and agree to the licensing terms.  Choose “Use an existing supported database” and select the DSN you created earlier from the drop-down list.  Select options appropriate for your environment in the following screens.  Choose to “Upgrade existing vCenter Server database” when the option is presented and the database will be upgraded to the new version.  This, by the way, is the point of no return – or at least, rollback is not easy from here…. But why would you want to go back?  As mentioned previously, I install all components to partitions other than C: but choose whatever you think is best.  I recommend keeping the port configuration to the default.  Go through the remaining screens and the install gets under way.  Generally, it’s a pretty reliable process.
  • Once the install is finished, check state of server and if happy with the install, disconnect the RDP or direct ESX session and connect to the vCenter server using your old client.  This should bring up a prompt to download and upgrade the client.  Accept the offer, follow the prompts and soon you should have the new client installed.  Log into the vCenter server – note the ability to use your Windows login (although you might not be able to use it yet as the old access roles disappear as a result of the upgrade!)
  • The service environment should be visible now but greyed-out.  This is expected.  To fix it, right-click on each ESX host and connect it as if they’re being added for the first time – providing the root credentials.  Click “Yes” to the message about the host being managed by VirtualCenter and that it will be disconnected it as a result.  This should make the host(s) come back to their usual state.  With this, your capability to manage the environment and VMotion etc. also returns to normal.
  • Go to “Home – Administration – Licensing” and add DNS name of the VirtualCenter server into the “License Server” box.  This is to allow existing ESX 3.5 hosts to connect to port 27000 on VirtualCenter server to validate licensing, until their licensing is transferred to the vCenter server.  At this point, you can also add the license key for vCenter server to take it out of evaluation mode.  Also, add vSphere license keys for the ESX hosts so that they can be transferred when required.
  • Go back to the vSphere Installer and this time, click on “VMware Converter” to install it.  Nothing special here.  I install it on a partition other than system, switch references to the server from IP address to FQDN, select the default port configuration and go ahead with the install.  Install the plug-in into the client by going to “Plug-ins…”.  If the plug-in is not there or not working properly, restart the client.  Remember that the plug-ins will have to be installed on each instance of the client separately.
  • Now it’s turn for the Update Manager install.  First we need to do some preparation.  Go to “SQL Server Management Studio” on the vCenter server and create a new database, to be used by Update Manager.  I usually call it vCenterUM.  Make your service account “dbo” for this database.
  • Double-click C:WindowsSysWOW64odbcad32.exe, select “System DSN” tab, select “SQL Server Native Client 10.0”.  Name the connection something appropriate (I call it “VMware vCenterUM”).  Make sure you select the correct SQL server from the drop-down list.  Change the default database to the one you just restored in the previous step.   In the end, test the settings to ensure that connection is successful.
  • The install is pretty simple.  Go back to the vSphere installer and click on “VMware Update Manager”.   After selecting appropriate language and accepting the license agreement, add the FQDN of the server you wish to use (in our case, it’s the vCenter server) and provide appropriate user credentials.  Select the correct DSN from the list in the database selection screen.  Provide any credentials if required.  Accept the default port settings.  Pay attention to the path where the updates are going to be stored.  If you have less than 20GB of space available, the installer will warn you.  I personally use it only to patch the ESX/vCenter estate so even 20GB should be enough but your requirements might be different.  If you already have patching mechanisms for Windows or Linux machines, then I would recommend keeping them and use this mechanism exclusively for the virtual infrastructure.
  • After the install, the plug-in is added to the client in the same way as we did for VMware Converter.  Again, it has to be done for each client that needs to participate in the patching process.
  • It is useful at this stage to go to “Update Manager Administration – Configuration – Patch Download Settings” and untick patch types “Linux”, “Windows” and also “VMware ESX” where “Description” says “Download ESX 3.x patches” (as you probably won’t be using them after the upgrade.
  • Tick “Use Proxy” and enter the appropriate proxy settings, if required.
  • Click “Test Connection”.  If the status next to patch types says “Connected” then the entries were successful.
  • At this point, you may wish to configure a backup routine for the server.  If you have server monitoring systems in place, adding this server to it will be a good idea too.
  • Don’t forget to implement your disaster recovery strategy for this server.

This brings us to a state where the environment is half-upgraded and old ESX 3.5 hosts are being managed by a new x64 vCenter server.  In the next and final part, we’ll go through the process of upgrading the ESX hosts and doing some cleanup.  Hopefully, I’ll see you there!