Migrate vCenter to vCSA in VMware View environment–Part 2

In the previous post I did a migration of my legacy vCenter server to the vCenter Server Appliance. I manually created the datacenter, cluster and folder structure with permission settings on the vCSA keeping the same layout as the legacy vCenter server. My three hosts where added to the cluster and all virtual machines moved from the Discovered virtual mahines to their respective folders. I also did a manual upgrade of the ESXi hosts from 5.0 to 5.1 using the esxcli software command.

I tried to find a guide using google to do this, but without any luck. Lets have a look at how I changed the vCenter server managing the desktop pools.

Disclaimer: The method described here are not confirmed or documented as a supported method by VMware and I take no responsibility for your actions. :)

VMware View – Change vCenter server on Pools

When deploying a virtual desktop pool, one of the initial settings or choices we have is which vCenter server we want to use. VMware View Manager can utilize multiple vCenter servers, but a desktop pool can only be pointing to a single vCenter server. The VMware View infrastructure running in this environment is VMware View 5.0 Permier, but non of the pools are linked clones. This is also one of the reasons we can migrate to the vCSA and eliminating the Windows server license.

Just a note; Previously the View Composer service had to be installed on the vCenter server – this does not apply any more. If you are using linked clone pools, you can still use the vCSA for the vCenter server service, but VMware View composer still have to be installed on a Windows server. I’m guessing that we’ll see the View composer service as a add-on to vCSA a few versions up the road.

In this environment, re-creating all virtual desktops weren’t really an option. Users were still logged in at their desktops, some of them with active/connected session and some with disconnected sessions. Reboot is also something the users dislike – bloody developers! Those demanding buggers…

Ok, so looking at the View Manager page, all pools seems to be ok even though the vCenter server defined on each pool was wrong. Clicking through the pools, no errors were listed at the pool or desktop lists. If I had tried to provision a new desktop by increasning one of the existing pools, it would fail because the defined vCenter server is not connected to any ESXi hosts, templates or even virtual machines.

We do want to add the vCSA to the View Manager to generate an ID for the vCSA in the View LDAP directory or “database”. This is done at the View configuration -> Servers -> vCenter server tab. Add the vCSA as any other vCenter server.

Luckily, the pool settings are defined in the View LDAP and these settings can be exported. The View LDAP is running on the connection server and can be exported by executing a vdmexport command on the server. Open a command promt or the VMware PowerCLI Powershell promt and execute the following;

PS C:\Pro..\VMw..\..View\Server\bin> vdmexport -f c:\ldap-export.ldif

Note: On View 5.0 the export will not be sealed and fully readable. On View 5.1, the vmdexport default to a sealed, non-readable file. Execute the vdmexport command with the -v option to get a readable file.

This will create a ldif file on c: named ldap-export.ldif which contains all configuration data for the respective View connection server. This is the file I edited to modify the pointer to vCenter from the old vc01 to the new vcsa01.

I first had to identify the ID of the legacy vCenter server and the vCSA by opening the ldif file in notepad++ and searching for the hostname. The IDs are fictious to make it easier to show the difference and modifications to be made.

The legacy vCenter server:

dn: CN=abcd1234-49cb-4fce-ae39-5dbcba9120d1,OU=VirtualCenter,OU=Properties,DC=vdi,DC=vmware,DC=int
changetype: add
objectClass: pae-PropertyObject
objectClass: pae-VirtualCenter
cn: abcd1234-49cb-4fce-ae39-5dbcba9120d1
pae-VCCreateRampFactor: 20
pae-VCUserName: root
pae-SVIUserPassword: {SSO-AES:1}ir+/2x2x2x2x2x2x2xx2x2x2x
pae-VCURL: https://vc01.v12n.local:443/sdk

This is the vCSA:

dn: CN=efgh5678-49cb-4fce-ae39-5dbcba9120d1,OU=VirtualCenter,OU=Properties,DC=vdi,DC=vmware,DC=int
changetype: add
objectClass: pae-PropertyObject
objectClass: pae-VirtualCenter
cn: efgh5678-49cb-4fce-ae39-5dbcba9120d1
pae-VCCreateRampFactor: 20
pae-VCUserName: root
pae-SVIUserPassword: {SSO-AES:1}ir+/2x2x2x2x2x2x2xx2x2x2x
pae-VCURL: https://vcsa01.v12n.local:443/sdk

The dn value is the ID of the vCenter server, in this case being the vc01.v12n.local and vcsa01.v12n.local.

Now, I had to find the pool definition and replace the defined vCenter server ID with the new one. By searching for the ID of the legacy vCenter server, I found a section looking something like this;

dn: CN=win7-auto-full,OU=Server Groups,DC=vdi,DC=vmware,DC=int
changetype: modify
add: pae-VCDN
pae-VCDN: CN=abcd1234-49cb-4fce-ae39-5dbcba9120d1,OU=VirtualCenter,OU=Properties,DC=vdi,DC=vmware,DC=int
-

The pae-VCDN is the value I modified. I replaced this VCDN ID with the on for the vCSA listed above:

dn: CN=win7-auto-full,OU=Server Groups,DC=vdi,DC=vmware,DC=int
changetype: modify
add: pae-VCDN
pae-VCDN: CN=efgh5678-49cb-4fce-ae39-5dbcba9120d1,OU=VirtualCenter,OU=Properties,DC=vdi,DC=vmware,DC=int
-

I repeated this operation for all the desktop pools administrated by the connection server. Do not execute a replace all in this document! Doing so will break the ldif file and you do not want to import a broken ldif file, trust me. I tried and ended up re-installing the View Connection server and import the initial exported ldap-export.ldif file. This was my first complete restore of a View connection server and I’m quite impressed how easy it was.

Once all pae-VCDN for all pools have been changed, save the exported file as a new file in case something goes wrong and we need to revert our changes. I saved it as ldap-export-modified.ldif.

To load the changes on the View connection server, open a command prompt or execute the Power CLI shell again and execute the following:

PS C:\Pro..\VMw..\..View\Server\bin> vdmimport -f c:\ldap-export.ldif

The vdmimport command will only inject modified settings to the LDAP directory and leave the others as they are. In this case, the only modification made is the pae-VCDN on the pools. Looking at the pool list in View Manager now, all pools are now pointing to the vCSA.

The View connection server service did not have to be restarted for the pool list to be updated – a simple refresh did the trick. I’m not sure if I restarted the View connection server service before increasing one of the pools. At first it failed due to missing customization specification defined in the pool settings, but a simple export – import of the specifications did the trick.

Right click the specification to export and use the import button in the menu bar to import on another server.

The infrastructure has been upgraded from ESXi 5.0 and vCenter 5.0 to ESXi 5.1 and vCSA  5.1.0. The VMware View desktop pools have successfully been migrated from the legacy vCenter server to the brand new vCenter Server Appliance. Remember the demanding developers? Guess what; non of the virtual desktops had to be rebooted or re-provisioned during this upgrade. I do have to reboot when upgrading VMware tools though, but that’s another story…