VMware Horizon Community
pmcwhorter
Contributor
Contributor

Move existing Vcenter, Connection Server & Security Server to new hardware

In the planning stages of the migration of my existing Horizon View environment (some linked clones & static vm's) to new hardware.  All infrastructure vm's (e.g., Vcenter) are virtual.  Because I'm moving to new hardware, I am not able to do an in-place upgrade.  Current environment: Vcenter 5.5 & Horizon View 6.0 with 4 ESXi hosts.  I'd like to move to Vcenter 6, Horizon View 6.1 with 3 ESXi hosts.  Most documentation that I've read refers to in-place upgrades using the same hardware.  Because of the marriage of Vcenter with View Connection & Security Servers, I'm hesitant to roll forward.  I would like to keep as much of the VDI environment intact without breaking everything.  One option, off the top, is to stand up a new Vcenter 6 server with old & new clusters (hardware) in the same datacenter?  Then slowly migrate from the old to the new cluster.

The migration to the new hardware doesn't have to be overnight.  I wasn't able to find any great documentation on this goal.  I'm sure that someone else has gone through this before.  If anyone has basic steps for the process, I'd greatly appreciate it.

Reply
0 Kudos
6 Replies
larsonm
VMware Employee
VMware Employee

Upgrade View to 6.1.  Build out your new vCenter and hosts.  Add the new vCenter to the View Connection Servers.  Move your parent over to the new vSphere hosts, create new desktop pools for the linked clones, recompose the linked clones.  Move the hosts with the with the full desktop into the new vCenter, create a new manual desktop pool for the full clones, import the desktops into the manual full clone pool, re-assign the users, and convert the manual pool to automated pool.

I'd recommend testing the approach on a small scale to verify your procedure and explore the nuances of your environment, as your mileage may vary.

Reply
0 Kudos
jkowalenko
Contributor
Contributor

I recently performed a couple similar migrations moving all servers from 2008 R2 to 2012 R2. The View environments were 100% linked clone desktops. This is a 3 step process:

  1. Upgrade View
  2. Move vCenter to new host
  3. Upgrade vCenter

The basic steps are:

  1. Upgrade View:
    • Backup all databases and take snapshots of all VMs.
    • Disable vCenter Provisioning in View Admin
    • Build up new 2012 R2 View Composer Server
      • install SQL Express and restore Composer database from backup
      • Install View Composer software using existing Database
    • After installation change the View Composer server in View Admin
    • Verify Domain Information, Enter User/Password if needed.
    • Turn provisioning back on and verify connection to Composer
    • Power off old Composer Server
    • Upgrade an existing 2008 R2 View Connection server (don't skip this step)
    • Build up new 2012 R2 View Connection Servers
      • "During install select "Replica" and point to the existing server you upgraded.
      • Repeat for all connection servers needed
    • Build up new 2012 R2 View Security Servers
    • Test functionality
    • After all new servers are online, uninstall View Components from old servers and power down.
  2. Move vCenter:
    • Backup all databases (SQL, ADAM) and take snapshots of all VMs.
    • Backup SSL Certs
    • Disable vCenter Provisioning in View Admin
    • Power off vCenter and delete computer account from Domain
    • Build new 2012 R2 vCenter server with same Name and IP address
      • Add to Domain
      • Install SQL Express and restore VCDB (UMDB optional)
      • Import SSL certs from backup
      • Create ODBC DSN's for SQL databases
      • Install vCenter Server software (Same version as you were running on old hardware)
      • Select "Use Existing Database" and "Keep my Data"
      • After install, Restore ADAM database
      • Reboot
    • Log into Web Client and verify functionality and no SSL errors
    • Reconnect Hosts if needed. (Might need to restart management agents)
    • Enable vCenter Provisioning in View Admin and test View Composer actions (recompose/refresh)
  3. Upgrade vCenter:
    • Perform documented in-place upgrade from vSphere 5.5 to 6.0

If you would like a more detailed plan, let me know!

Jeff Kowalenko - VCAP5-DCA, VCP5-DCV, VCP6-DTM, CCNA Black Bull Consulting
Reply
0 Kudos
sayhi2vigneshba
Contributor
Contributor

Hi larsonm , are there any KB articles or links with the detail migration procedure , in my environment i have around 300 machines of linked clones and 200 machines of full clone , iam much worried about the linked clones part only as i have no backup procedure its a one way go.. it will be great if you share such links.

Reply
0 Kudos
larsonm
VMware Employee
VMware Employee

I can't say whether the approach is documented anywhere.  This is a high level approach that I have used to help multiple customers migrate.

The linked clone side has about as much impact as a recompose.  You are imply pulling the same parent into a new vCenter, and creating a pool using the same snapshot as the previous pool.  The linked clones would then be re-created as they were before.

Are you using floating or dedicated assignments on the linked clone pools? Do you have persistent disks associated with your linked clones?

What questions/concerns do you have?

Reply
0 Kudos
sayhi2vigneshba
Contributor
Contributor

Recomposing would not be a problem in my case.

Yes i use dedicated assignments in linked clone pools with the persistent disks associated with the linked clones

My question and concern is whether any data loss will happen and while migrating will there be any impacts apart from the Recompose ?

Reply
0 Kudos
larsonm
VMware Employee
VMware Employee

The only data that's part of this equation is the data on the persistent disks, which makes things a little more complicated.  I assume you'll want to keep the data on the persistent disks.  If that's the case, you'll need to detach the persistent disks from the desktops and add them to the new desktops.  Here's an article on the topic:  https://vmfocus.com/2013/07/09/view-5-2-moving-persistent-disks-to-another-pool/

I typically do not use persistent disks in my deployments.  I believe you can move away from persistent disks by deploying Persona Management or UEM, and eliminate the persistent disks altogether.  Test it thoroughly, as your mileage may vary.

Reply
0 Kudos