Hi,
I currently have an environment containing 17 ESXi 4.1 hosts being managed by VC 4.1. The old VC physical server is to be decommed and a new one installed along with several additional ESXi 5.5. servers to increase capacity, allow for 2012, Solaris 11 etc. Storage is Netapp on NFS where SAN connected and includes seperate vfilers for separate security contexts, current VSC version is 2.1 . The end state will be VMware 5.5 products however the VSC version will be 4.2.1 to cater for legacy 32 bit operating systems. It is crucial that we don't lose any backups (or have them orphaned) and if possible I want to avoid having to create a new baseline so therefore intend to move the .xml file containing the backup jobs from the old VSC2.x and put this onto the new instance.
Using the approach below does anyone know of any problems/gotchas etc and will this solution work while preserving all backups ??
Thanks in advance
Cameron
Upgrading to vSphere 5.5
It is assumed that we will run in parallel and to allow rollback. The 2 virtual centre instances namely the legacy vc-01 server and the new 02 server primarily to allow the backup from the legacy backup jobs to the old environment during the cutover period to the full new implementation . At this point we need to ensure that the 7 days on site and 30 day offsite retention is maintained, this is key.
There are basically four steps to be completed when upgrading to vSphere 5.5 in this scenario:
1. Upgrade the vCenter Server
In this case we are going to install a new VCentre server and run these 2 VC instances in parallel to allow rollback functionality.
Pre-requisite tasks
• Procure suitable server for vCenter
• Cabling requests for following servers
o Cabling request for new physical VC server
o Cabling request for 2 new DC ESXi Nodes
o Cabling request for 2 new DMZ ESXi Nodes
o Cabling and Switch configuration request for VMotion network for DMZ to remove crossover.
vCenter Server software requirements
vCenter Server requires a 64-bit operating system, and the 64-bit system DSN is required for vCenter Server to connect to its database.
Pre-upgrade software requirements
• vCenter Server requires the Microsoft .NET 3.5 SP1 Framework.
• vCenter Server 5.5 removes support for Windows Server 2003 and Windows Server 2008 SP1 as a host operating system.
• Microsoft SQL Server 2008 R2 Express database is limited in number of hosts and number of VM's therefore a full SQL install with latest version numbers is recommended. . This would require an additional SQL licence.
• NetApp VSC 4.2.1 is compatible with vSphere 5.5, however is not the most up to date version, we require to use this version as e still have residual 32bit operating systems within the estate, and is therefore recommended. We currently run VSC 2.1.2
Therefore the steps are as follows:
• Procure new Windows Server and SQL licenses
• Completion of cabling
• Rack and stack new physical Vcenter server.
• Install/configure W2012 server
• Install/configure latest SQL version
• Install/configure vCenter 5.5
• Install/ configure NetApp VSC 4.2.1
• Ensure all required firewall rules are in place for new VCentre instance
• Test all connectivity
2. Perform the ESX uplift SAN connected
This assumes the additional nodes are all in place and therefore the steps are as follows:
• Create test VM’s on required contexts DC, DMZ, etc
• Add to existing backup job
• Remove DMZ node from old VCenter server vc-01 (no data so mitigates risk )
• Add node to new VCenter server
• Check restore capability on test VM
• Repeat as required minus one node for roll back across all datacentre contexts
• VMotion from node to be upgraded
• Upgrade node
• Check configuration
• VMotion VM back
• Retest restore of test VM.
• After 7 day retention period is over repeat for final nodes required across all datacentre contexts
• ensure that the 30 day off site retention isn’t broken.
A second PREFFERED option may be available where we import the old backup jobs into the new VC instance, this approach to be confirmed by the storage SME’s. The required steps are as follows:
The following steps must be taken to protect SMVI when installed on local disk:
• Backup the following two directories
• %PROGRAMFILES%\NetApp\SMVI\Server\repository\
• %PROGRAMFILES%\NetApp\SMVI\Server\etc
• In the event of failure of the SMVI server, install SMVI on a replacement system.
• Stop the SMVI service
• Copy the backed-up files listed in step 1 to their original location.
• Restart the SMVI service within Windows.
• Start the SMVI GUI and enter “Setup’”.
• Enter the vCenter server name or IP address.
• Enter the necessary storage information
• Select “Restore” from within the SMVI GUI.
Backup jobs will be listed and scheduled jobs will run successfully. (this would need to be tested)
https://communities.netapp.com/thread/32680
3. Perform the ESX uplift local storage
This is to be performed on tier 1 POP sites some with only local storage and another site SAN connected to a separate filer. The 2nd SAN connected site site will additionally have a hardware upgrade where the G7’s will be replaced by Gen8 servers.
Sites 1 local storage
• Ensure all comms have been issued
• Create test VM and add to OSSV backup schedule this gives us a non critical VM for test purposes
• Ensure all VM’s have been backed up
• Powered down VM’s
• Power down node
• Upgrade to 5.5
• Power on host
• Test
• Remount local data store
• Power on VM’s
• Test connectivity etc
Site 2 (SAN connected )
• VMotion all VM’s to single node
• Swapout one node to Gen8
• Install configure ESXi 5.5
• Add to VC
• Create test VM and add to OSSV backup schedule
• Ensure all VM’s have been backed up
• Test connectivity etc
• VMotion VM’s to new server
• Power down node
• Upgrade to 5.5
• Power on host
• Test
• Remount local data store
• Power on VM’s
• Repeat procedure
4. Upgrade the virtual machines (VMs )
You will need two components to upgrade the VMs: the VMware tools and virtual hardware.
• create a snapshot prior to starting the tools upgrade.
• update the VMware tools
• a snapshot prior to upgrading the virtual hardware
• shut down the VM.
• upgrade Virtual Hardware.
• power on the VM.
• test
• remove snapshots once confirmed.