Change OS (update from Windows 2008 to Windows 2012 R2) of vCenter 5.5 – Change vCenter 5.5 SSO architecture, virtualize a physical vCenter 5.5

Change OS (update from Windows 2008 to Windows 2012 R2) of vCenter 5.5 – Change vCenter 5.5 SSO architecture, virtualize a physical vCenter 5.5

1. Summary

The following checklist describes the process of migration (update) the vCenter 5.5 OS (for example from Windows 2008 to Windows 2012 R2) by actually re-installing a fresh vCenter 5.5 – using the exsisting vCenter database, inventory database and certificates. A following step could be to update this “refreshed” vCenter 5.5 to vCenter 6.0. – And yes I am talking about Windows vCenter to Windows vCenter I am not talking about vCenter appliance.

I had various questions from customers running vCenter 5.5 on outdated OS, or still running vCenter on a physical server. That’s why I collected the steps to get to a redesigned vCenter which will be seen just as the “same” from all surrounding apps like AV or backup etc.

This upgrade will be done in five different phases. This ensures a minimal production impact and various fallback possibilities at different points in time. Fallback is always possible.

CAUTION: If you are running additional services on your vCenter server always double check compatibility with your target system. – For example vSphere Authentication Proxy only supports IIS 6 and IIS 7 – so it would not be compatible with Windows 2012 or later. (http://kb.vmware.com/kb/2058689) – always check Product Interoperability matrix and Solution/Database Interoperability first before updating! http://partnerweb.vmware.com/comp_guide2/sim/interop_matrix.php?

The five migration phases are:

  1. Build a new virtual server running Windows 2012 R2 using the existing vCenter and inventory databases. – This step will be done during the first maintenance window. (During this upgrade, all virtual servers and ESXi hosts will continue to run without interruption.) – Only vCenter actions such as create/delete VMs or taking snapshots etc. will not be possible. High availability of virtual machines is NOT affected. Duration of this maintenance window is about 8 hours.
  2. Step two, which will be at a later point in time, will be the actual upgrade of the refreshed vCenter from version 5.5 to version 6.X. For this step, there will be another maintenance window of about 4 hours. Otherwise the same access and availability situation as for step one
  3. Step three will be upgrade of ESXi hosts. This can be a rolling update – cluster by cluster. The current configuration allows upgrade during normal operation times, as there is always room for a single ESXi failure (or maintenance.
  4. Step four will be upgrade of VMware Tools for the virtual machines. All VMware Tools should be upgraded to Version 10.0.5 or higher. – This step can be combined with Windows or Linux patching cycles and it can be done at any time – even before the upgrade of vCenter!
  5. Last step will be the upgrade of virtual machine hardware. This has to be done after VMware Tools upgrade and after the ESXi host upgrade. This step requires virtual machine reboot and therefore can be combined with regular guest OS patching.

2. Upgrade Flow

2.1       Prerequisites for vCenter Migration/Upgrade

The following prerequisites should be met before the upgrade:

 

  1. passwords:
Domain Administrator
Local Administrator account old vCenter Server
Local Administrator account new vCenter Server
Old vCenter administrator@vsphere.local
New vCenter administrator@vsphere.local
old vCenter SQL sa
New vCenter SQL sa

 

  1. Remote Access (DRAC/ILO) to old physical vCenter Server
  2. Installation sources for Windows Server 2012
  3. Installation sources for MS SQL Server 2014
  4. Installation sources for vCenter 5.5
  5. Installation sources for vCenter 6.0 Update X
  6. Rvtools installed on a Management station

3. Phase 1 – Migration physical vCenter 5.5 to virtual Windows Server 2012 R2 – or migrate vCenter 5.5 to another Windows OS

3.1       Preparation

  1. Create a new virtual Windows 2012 R2 server with latest patches and latest VMware Tools.
    1. Temporary name
    2. NOT joined to domain
    3. .NET 3.5 Feature has to be installed
  2. SQL Server should not be installed on the same VM as vCenter server. This is only acceptable for very small or LAB environments – details see vCenter Installation documentation. For larger environments have an existing SQL server ready to host vCenter db or install a dedicated SQL server for vCenter.

3.2       Migration

These are the steps for the actual migration. – On the “old” vCenter do the following:

  1. If necessary disable DRS on the cluster where the old vCenter Server
    is running
  2. Create an inventory with rvtools on your management server
  3. Stop and deactivate all vCenter Services
  4. Backup vCenter certificate on a central backup store
    C:\ProgramData\VMware\VMware VirtualCenter\SSL.
  5. Backup vCenter WebClient certificate on a central backup store
    C:\ProgramData\VMware\vSphere Web Client\ssl
  6. Backup vCenter SQL database and copy file to central backup store (and write down permissions for vc db (SQL Server should not be installed on the same VM as vCenter server. This is only acceptable for very small or LAB environments – details see vCenter Installation documentation)
  7. Write down ODBC configuration
  8. On the source machine, stop the Inventory Service (if still running)
  9. On the source machine, open the command prompt and change the directory to
    vCenter_Server_installation_directory\Infrastructure\Inventory Service\scripts
  10. Run the following command to back up the Inventory Service database.
    bat -file backup_file_nameWhen the backup operation finishes, the message Backup completed successfully appears. Copy file to central backup store
  11. Copy the SSL certificate from source path C:\ProgramData\VMware\Infrastructure\Inventory Service\ssl\
    to your backup store
  12. Export all Customization Specifications to the central backup Store
  13. Note ESXi host where the newly created Windows server resides
  14. Shutdown the “old” vCenter

On the newly created virtual vCenter server do the following:

  1. Shutdown server
  2. Create snapshot (connect to ESXi host where this virtual machine resides)
  3. Delete Active Directory account of physical vCenter server
  4. Start and login to the new virtual server, change server name (same as “old” vCenter Server)
  5. Change IP address of the NEW server (same as “old” vCenter Server)
  6. Add server to domain
  7. Installation of SQL Server 2014
    Management Tools, Client Tools & Backwards Compatibility (SQL Server should not be installed on the same VM as vCenter server. This is only acceptable for very small or LAB environments – details see vCenter Installation documentation) (if SQL is installed on a separate server just install SQL Native Client on vCenter Server
  8. Start SQL Agent and configure AUTOMATIC start
  9. Restore vCenter db and set permissions
  10. Create vCenter ODBC Connectors
  11. Create new Update Manager db
  12. Create vCenter ODBC Connector
  13. Create path and Restore vCenter certificate
    C:\ProgramData\VMware\VMware VirtualCenter\SSL.
  14. Create path and Restore vSphere Web Client certificate
    C:\ProgramData\VMware\vSphere Web Client\ssl
  15. Create path and restore Inventory certificate
    C:\ProgramData\VMware\Infrastructure\Inventory Service\ssl\
  16. Start custom install for vCenter – then install new SSO service
  17. Install vCenter 5.5 WebClient
  18. Install vCenter 5.5 Inventory service
  19. Install vCenter 5.5 Service using the restored vCenter database
    (accept database Upgrade if you are using latest VC 5.5 Update)
  20. Install Update Manager
  21. Install vCenter Client
  22. Stop the Inventory Service.
  23. Open the command prompt and change the directory to
    vCenter Server install location\Infrastructure\Inventory Service\scripts.
  24. Run the following command to restore the Inventory Service database.
    restore -backup backup_file_name
    When the restore operation finishes, the message The Restore completed successfully message appears.
  25. Restart the inventory service
  26. Login to vCenter and check functionality
  27. Import all Customization Specifications to the central backup Store
  28. Restart vCenter VM
  29. Check functionality
  30. If all is ok – remove vCenter Server snapshot
  31. If necessary enable DRS on the cluster where the vCenter Server
    is running

3.2.1     Fallback

In case something happened:

  1. Shutdown virtual vCenter Server
  2. delete vCenter domain account
  3. if SQL Server was on a separate server – restore old vCenter database
  4. Start the old physical vCenter Server
  5. Add server to workgroup – add server to domain
  6. Activate all vCenter services
  7. Restart server

4. Phase 2 Upgrade the virtual vCenters to vSphere 6

4.1       Upgrade

  1. Findout on which host vCenter is running
  2. Connect latest vCenter 6 ISO to vCenter
  3. Shutdown vCenter
  4. Start vSphere Client and direct connect to host where vCenter runs
  5. Create Snapshots of vCenter
  6. Start vCenter
  7. Start update process for vCenter 6
  8. Check functionality
  9. restart vCenter Servers
  10. check functionality
  11. if successful delete snapshot

4.1.1     Fallback Scenario

  1. Find out on which host vCenter is running
  2. Start vSphere Client and direct connect to host where vCenter runs
  3. Shutdown vCenter
  4. Revert to snapshot
  5. Re-start vCenter
  6. check functionality

5. Phase 3 – Upgrade ESXi Hosts

Before the upgrade of an ESXi cluster, we should move a test-VM to this cluster and configure it to the clusters “local” network(s). This will help us to do a ping test before migrating production VMs to a new host.

5.1       Host Upgrade

  1. Set one ESXi Host to maintenance mode
  2. Set DRS to manual
  3. Shutdown ESXi Host
  4. Update BIOS and Firmware of all adapters
  5. Update ESXi to version 6.X
  6. Update ESXi to latest patch version
  7. Install storage plugins if necessary (NetApp Plugin)
  8. Release host from maintenance mode
  9. Migrate test VM to new host
  10. Do basic connectivity test of migrated VM
  11. Set DRS to automatic
  12. Repeat procedure for next ESXi host in cluster
  13. If all hosts are updated set DRS back to automatic

5.1.1     Fallback

  1. Re install ESXi host with ESXi 5.5
  2. Configure host and add to cluster

6. Phase 4 – Upgrade VMware Tools

VMware Tools inside the virtual machines have to be updated to the latest version (10.0.5 or higher). – This update is not dependent of any other update. It can happen any time. This step requires reboot of the updated VM. The latest tools are supported by vSphere 5.5 as well as vSphere 6.

VMware tools can either be updated using Update Manager or via software deployment products.

7. Phase 5 – Update virtual hardware

As soon as the VMware Tools are updated and the host I running ESXi 6 virtual hardware can be upgraded to the latest level.

This again requires a reboot of the virtual machine.

Leave a Reply

Your email address will not be published. Required fields are marked *