I was recently in a situation where I needed to retain an existing vCenter Server (5.0) managing a number of clusters and build a new vCenter Server (5.5), then move a single cluster to this new vCenter (including with it a number of ESXi servers and VMs).

After which the ESXi servers would be upgraded and the VMs running on those hosts.

This is a pretty straightforward process if you are only using vCenter server to manage server virtual machines and can be done without any downtime to the VMs.

However if this vCenter Server is used to manage and provision your desktops in a Horizon View environment then it's unfortunately it's not that simple.

More importantly it is not officially possible and completely unsupported by VMware to move View desktops to another vCenter Server.

This is quite clearly stated in kb.vmware.com/kb/1018045 (Moving View-managed desktops between vCenter Servers is not supported 1018045)

So clear infact the message is in bold red text!

"IMPORTANT NOTE: Moving View-managed desktops between vCenter Servers is NOT supported."

VMware recommend that you re-create the desktop pools on new vCenter Server rather than migrate them.

This is because if you move or migrate the VMs and/or hosts the virtual desktops will show as missing in View Administrator.

You cannot just disconnect and connect the hosts to a new vCenter server and change the address in View. That WILL break VMware View, trust me!

Why would I want to perform such an action?

I'm currently working at a managed service provider and there are several customers using this vCenter server for their managed virtual desktops.

I need to be able to move one customer off to a dedicated instance of vCenter for their View environment. This new vCenter will be 5.5 U1, thus enabling them to have Windows 8.1 desktops and use vFlash (once the hosts have been updated) and of course dedicated to their VDI environment.

Why not re-create the desktop pools?

These full clone desktops. View Composer is not being used. If View composer was being used I possibly could have re-created the desktop pools from the master image with relative ease.

However in this specific case each user is assigned a desktop and has their own applications and data in each VM and re-creating the pools would mean losing all of this and starting with a clean mater image. Generally speaking this would = unhappy users.

Again I could also come up with some plan to build some new hosts along side the existing ones, copy the VMs or copy the LUNs the VMs are on to retain them and/or make a manual pool.

But ideally we want to keep this as an automated pool and also perform all this work in such a fashion the customer will not be interrupted at all (apart from the VMware Tools update as per usual).

Are there any other reasons I would want to do this?

Yes, if you wanted to move View from a Windows based vCenter server to the vCenter server appliance (vCSA), or vice-versa you could move View between vCenters following the steps below.

If you were simply upgrading vCenter you should not need to build a new vCenter server and migrate your View environment to it.

Just so you understand the task being performed herein is not supported by VMware, nor myself for that matter.

If you choose to follow my steps, please ensure you understand fully what you are doing and how vCenter and View work indepth.

Please do not try this if you do not feel entirely comfortable or understand what is being done when reading the steps. 

And of course make sure you have a full backup of your vCenter database, vCenter server, View Connection Server, View database, desktops and any data within them.

Ok that should be enough warning now for you to get the picture.

Lets have a look at an overview of what we are going to perform:

• Backup everything!
• Build new vCenter Server
• Re-create Datacenter, Cluster, Resource Pools and Folder structure on new vCenter Server
• Add new vCenter Server into View
• Move ESXi hosts to new vCenter Server
• Move VMs/templates to the correct locations
• Edit View LDAP database
• Testing

1. Backup Everything!

Backup your entire environment; vCenter database, vCenter server, View Connection Server, View database, desktops and any data within them.

Take full notes of the inventory objects and locations of VMs within this inventory as you will need them later in this process.

2. Build your new vCenter Server

This can be the same version as your current vCenter Server or a newer version. As long as VMware View supports that version.

I certainly wouldn't recommend installing an older version than you're currently using.

The new vCenter server could be a Windows based server or the vCenter Server Appliance (vCSA).

3. Re-create Datacenter object on new vCenter Server

Create the Datacenter on the new vCenter in which you will create the cluster.

You MUST create the Datacenter name exactly as on the current vCenter

e.g. "London"

5. Re-create Cluster object on new vCenter Server

Create the cluster on the new vCenter ready for the hosts to be added to it.

You MUST create the cluster name exactly as on the current vCenter

e.g. "CustomerX-VDI-Cluster"

Note: You should also create the cluster HA/DRS settings exactly as the existing cluster, although this will not affect View itself.

6. Re-create Folder structure on new vCenter Server

Re-create the folder structure exactly as the existing structure on your current vCenter.

It is imperative this is correct otherwise View will fail to find the virtual machines and report them as missing. As in the case the datacentre or cluster is incorrectly named.

7. Add new vCenter Server into View Administrator

Note: Do not remove your old (current) vCenter server!

In View Administrator, go to your "Servers" and add your new vCenter server.

This creates a new vCenter Server object in the View database along side your existing one.

8. Move your ESXi hosts to the new vCenter Server

Note: Check you are not using distributed vSwitches before doing this. If you are you need to migrate to standard vSwitches and migrate the VMs to this before you move the hosts.

Note 2: Before moving anything make sure you have a full listing of the inventory and where the VMs are located (resource pools and folders).

On your old vCenter Server, disconnect and then remove your ESXi hosts.

On your new vCenter Server add your ESXi hosts to the cluster object you created earlier.

Ensure your virtual machines all appear correctly.

9. Configure the additional Cluster HA/DRS settings

Now the hosts and VMs are added to the cluster you can configure the settings that you otherwise couldn't.

Create the resource pools named exactly as per the old vCenter Server.

Configure the per VM HA/DRS settings if required now the VMs are on the new vCenter.

10. Add your templates to the inventory

Browse the datastores where your templates are stored

Add the .vmxt to the inventory named and located exactly as previously found within vCenter

10. Move the VMs to their correct folders

This is quite self explanatory, however you must ensure the VMs are placed in "ExAcTly" the same folder name within the exact same structure as the previous vCenter.

e.g. root --> Datacenter --> Desktops --> Finance Desktops

11. Move the VMs to their resource pools

This is also quite self explanatory, however you must ensure the VMs are placed in their correct resource pool.

e.g. "RP-Directors-Desktops"

12. Export the View LDAP Database

This is the interesting part.. currently your View environment will be going oh my lord where have all the desktops gone and stating them correctly as "missing"! Yes it's quite scary and I've seen that a few times for many different reasons, but that's another story!

Now we want to export the View LDAP database edit it and import it back so View knows where to find the desktops.

Open an admin command prompt (cmd.exe)

cd C:\Program Files\VMware\VMware View\Server\tools\bin

vdmexport -v -f C:\view-ldap-export-before.ldif

13. Find your vCenter Server DN in the View LDAP file

Open the export file C:\view-ldap-export-before.ldif in notepad or something like Notepad++ which is what I used

Search for your old vCenter server, such as by IP or FQDN (as it appears in View).

You want to find a section defined like below with "objectClass: pae-VirtualCenter".

dn: CN=a393ccba-cdee-4094-acff-049b27b7f6cd,OU=VirtualCenter,OU=Properties,DC=vdi,DC=vmware,DC=int
changetype: add
objectClass: pae-PropertyObject
objectClass: pae-VirtualCenter
cn: a245bc6a-cdee-4094-acff-049b27b7f6cd
description: OLD VCENTER
pae-VCCreateRampFactor: 8
pae-VCSslCertThumbprint:: abcded123456gremovedabcded123456gremovedabcded123456gremovedabcded123456gremovedabcded123456gremovedabcded123456gremovedabcded123456gremoved
pae-VCUserPassword: {SSO-AES:1}abcded123456gremovedabcded123456gremovedabcded123456gremovedabcded123456gremovedabcded
pae-VCDeleteDampFactor: 5
pae-VCSslCertThumbprintAlgorithm: DER_BASE64_PEM
pae-VCURL: https://10.1.1.10:443/sdk
pae-Disabled: 0
pae-SVIUserPassword: {SSO-AES:1}hN+8aR/8azxU8b/s282CVvSD9OYM8YgRIomDHTaVZnr3quIhTjQCOg==
pae-VCUserName: domain\svc-view
pae-SVIUserName: domain\svc-view
pae-NameValuePair: UNIQUEID=20

Then do the same for your new vCenter Server.

dn: CN=d48df3b-efd3-4dab-b1fe-cb7b18062208,OU=VirtualCenter,OU=Properties,DC=vdi,DC=vmware,DC=int
changetype: add
objectClass: pae-PropertyObject
objectClass: pae-VirtualCenter
cn: 3ba0a17a-efd3-4dab-b1fe-cb7b18062208
description: NEW VCENTER
pae-VCCreateRampFactor: 20
pae-SVIType: 0
pae-VCAllRefitRampFactor: 12
pae-CBRCEnable: 0
pae-VCSslCertThumbprint:: abcded123456gremovedabcded123456gremovedabcded123456gremovedabcded123456gremovedabcded123456gremovedabcded123456gremovedabcded123456gremoved
pae-VCUserPassword: {SSO-AES:1}abcded123456gremovedabcded123456gremovedabcded123456gremovedabcded123456gremovedabcded
pae-SVICreationRampFactor: 8
pae-VCDeleteDampFactor: 50
pae-VCSslCertThumbprintAlgorithm: DER_BASE64_PEM
pae-VCURL: https://10.1.1.20:443/sdk
pae-SeSparseReclamationEnable: 0
pae-Disabled: 0
pae-SVIUserPassword: {SSO-AES:1}abcded123456gremovedabcded123456gremoved
pae-VCUserName: domain\svc-view
pae-NameValuePair: UNIQUEID=24

Ultimately you want to be able to take note of the DN for each of your old and new vCenter Server, such as (which will be uniquely different to below):

Old vCenter 

dn: CN=a393ccba-cdee-4094-acff-049b27b7f6cd

New vCenter

dn: CN=d48df3b-efd3-4dab-b1fe-cb7b18062208

14. Edit the View Pools in the View LDAP file

Search your exported LDAP file with the DN of your old vCenter Server. You will find sections such as below naming the desktop pools with a "pae-VCDN" line.

This is what tells View which vCenter that desktop pool is located on.

Note: Do not perform a find and replace. We only need to change these desktop pool entries. The old vCenter server will be removed from View Administrator cleanly and safely later.

dn: CN=Windows-7-Finance-Pool,OU=Server Groups,DC=vdi,DC=vmware,DC=int
changetype: modify
add: pae-VCDN
pae-VCDN: CN=a393ccba-cdee-4094-acff-049b27b7f6cd,OU=VirtualCenter,OU=Properties,DC=vdi,DC=vmware,DC=int

We simply need to modify the "pae-VCDN:" line to the DN of our new vCenter server:

dn: CN=Windows-7-Finance-Pool,OU=Server Groups,DC=vdi,DC=vmware,DC=int
changetype: modify
add: pae-VCDN
pae-VCDN: CN=d48df3b-efd3-4dab-b1fe-cb7b18062208,OU=VirtualCenter,OU=Properties,DC=vdi,DC=vmware,DC=int

Repeat as required for all your desktop pools.

Then save the file as C:\view-ldap-import.ldif

15. Import the modified View LDAP database file

Open an admin command prompt (cmd.exe)

cd C:\Program Files\VMware\VMware View\Server\tools\bin

vdmimport -v -f C:\view-ldap-import.ldif

The View LDAP database will be modified changing the vCenter used for those desktop pools.

Now restart the "VMware Horizon View Connection Server" service.

16. Login to View Administrator and check the desktop pools

In the pool overview the desktop pools should now show as being on your new vCenter Server e.g. newvcenter.domain.com.

It will take a few moments for all the desktops to report as available and may say "(missing)" until they do. But after 2 minutes they should all be showing as available or connected etc.

If not then check that the VMs are in the correct folders and nothing has been named incorrectly.

17. Remove your old vCenter Server from View Administrator

If you are unable to remove your old vCenter server because View still believes there are desktop pools managed by that vCenter, see here Unable to Remove vCenter Server from View Administrator

18. Final things to tidy up

Import your host profiles and configure.

Import your guest OS customisation profiles.

Test you can connect to a desktop.

Test creating a new desktop in each pool and ensure they provision correctly.

Remove your old vCenter Server from View

Continue on with your upgrade, upgrade your ESXi hosts, update VMware tools in the virtual machines.

I hope this is of great help to others in a similar situation to myself.

It's all very well not supporting such a migration process from a vendor perspective, however virtualisation solutions including VDI solutions have been sold, marketed and designed to be highly available with minimal downtime. In this case that promise would somewhat have been broken.

As such I have been able to move a customers View environment from one vCenter to another without rebuilding it, but also without any downtime.

Because the client devices were using a direct connection to the desktop rather than tunnelled via the connection server, a single desktop session was never dropped for a user!

We retained the automated desktop pool within View and the user assignments to their desktops.