Thursday, 21 October 2010

Migrating from 32bit Virtual Center to 64bit vSphere 4.1 Virtual Center on a New Database

With the advent of VMware vSphere 4.1, companies with 32bit Virtual Centers will be needing to rebuild these on 64bit systems. There are plenty of articles out there with walkthroughs on how to use the Data Migration tool to migrate from a 32bit to a 64bit Virtual Center, and we will not go into this here. Instead, we shall look at a different scenario:


Scenario:

A small company with 7 hosts in two clusters; 1 cluster of 4 hosts is EVC enabled, the other cluster of 3 hosts is not EVC enabled. The database on the existing vSphere 4 32-bit Virtual Center has grown to over 20GB (in vCenter, estimated space required for 7 hosts and 140 VMs on default settings is just 1.32GB,) so the decision is taken to start afresh with a new database. The decision is also taken to keep the same name and IP address.

Complicating matters – the company uses Veeam Backup and Replication (on v4.1.1,) and has a small 20 seat XenDesktop 4 VDI environment, both of which talk to the Virtual Center server.


Walkthrough and issues encountered:

1) Build Windows 2008 R2 Enterprise server with same name and IP Address as original

2) Install SQL 2008 R2 Express (recommend doing this as comes with a 10GB database limit, whereas the SQL 2005 Express bundled with the vCenter 4.1 installation media only has a 4GB limit)

3) Create a 64bit System DSN for the Virtual Center database and a 32bit System DSN for the Update Manager database

4) Install Virtual Center 4.1

5) Create datacenter and clusters in the new Virtual Centre as a copy of the original

6) Install Update Manager 4.1


Switch over day:

1) Shut down old Virtual Center and reset its account in AD

2) Join the new 64bit Virtual Center to the domain

3) On the non-EVC enabled cluster, the hosts could be added into the new VC without any down time of guest machines

4) On the EVC enabled cluster, hosts could not be added into the new VC without having to shutdown all the guests on the host prior to adding (being in maintenance mode is not a requirement)

Error: The host cannot be admitted to the cluster’s current Enhanced vMotion Compatibility mode


5) Once all the resource pools had been put in place as per the original; time to test the Citrix XenDesktops, and Veeam Backups, and deal with any niggling issues


Citrix XenDesktop 4

These would not initially work as the Citrix Desktop Delivery Controller could not talk to the new VC. The fix was to edit the proxy.xml file on the Virtual Center server. The location of proxy.xml is:

C:\ProgramData\VMware\VMware VirtualCenter

Edited so that the section for type = vim.ProxyService.LocalServiceSpec, and port 8085, and serverNamespace = /sdk - has accessMode changed from httpsWithRedirect to httpAndHttps (see image below):
Change to:
(And restart vCenter Server service to apply changes to proxy.xml)

All the virtual desktops had to be removed from their groups and be re-added, with users reassigned to their desktops.


Veeam Backup 4.1.1

Virtual Machines had to be re-added to their jobs, and the old entry removed. Replicas needed to be kicked off from scratch.


Other Issues:

1) Unable to assign permissions under Domain accounts via the vSphere Client, a search would bring up no accounts

Error -> Call “UserDirectory.RetrieveUserGroups” for object “UserDirectory” on vCenter Server failed


The solution was to have the ‘VMware VirtualCenter Server’ service log on as a domain account (the domain account used must also have permissions to the VIM_VCDB database)

2) In Update Manager, all the settings were greyed out

Possibly a side effect of installing Update Manager on the Virtual Center whilst the machine was still in a workgroup. A few things were tried … Update Manager was uninstalled. When trying to reinstall Update Manager, this error was encountered:

Error 25085.Setup failed to register VMware vCenter Update Manager extension to VMware vCenter Server:


The fix outlined in -

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1024795

was to use ADSI edit to add CN=com.vmware.vcIntegrity which was missing, and then the install ran fine.

No comments:

Post a Comment