VMware Labmanager 4 & vCentre Upgrade
Let me start by saying that VMware usually have most bases covered when it comes to documentation, but it seems that they dropped the ball a little bit on this one.
I am sure that most of you reading thins who have VI 3.x are considering or have already started the move to vSphere 4.1. There are some great documents from VMware to discuss the three core steps
- Upgrade vCentre and its components
- Migrate your ESX hosts to ESXi (you can in place on ESXi 3.5 to 4.1 if you wish) Whilst technically ESX is supported for the last time its best to move away from it if you can replace your management and ops tasks in the service console.
- Upgrade your VM’s tools and hardware
My problem was that there was nothing to talk about the effect that vCentre has when it’s also being used by Labmanager.
I knew that Labmanager throws its toys out of the pram if a resource pool is deleted and re added with the same name so imagine the fun it would have with the vCentre name changing!!
Here was my high level plan (only the steps relevant to Labmanager are noted)
- Setup a new x64 server for a new vCentre with a new name, install the pre reqs and setupa 64-bit DSN.
- Backup the existing vCentre server with a clone and backup the SQL DB
- Use the data migration tool to backup all the current vCentre config. I also backed up the SSL folder for good measure
- Run the vCentre host migration utility and copy the folder to the new vCentre
- Call the setup from the copied folder and allow it to upgrade the DB schema and auto upgrade the hosts.
- Then as advised by VM support go into LM and just change the vCentre name to the new one.
Wrong! Well the actual vCentre migration went great, it was the changing of the LM vCentre where it all crashed and burned. After that change the ESXi host was all grayed out and had a nice red cross next to it even though it was the same and untouched. Nothing could be deployed etc..
So I decided to remove the host, re-add it and prepare it again. Up on trying to re-add it I would get an error attaching to the resource pool. To cut a long story short after a tonne of troubleshooting with VM Support we realised that the LM version had to be upgraded – D’oh!! As soon as that happened I could attach to a resource pool, prepare the host and all was well.
The VM support guy also took my feed back on board and said that we should have taken more steps as well before the migration and that just changing the vCentre name is not enough. Maybe by the time this has been published it will be a KB artical as promised. Below are the steps you should take, I hope this saves someone some time in the future and serves as a reminder to always RTFM to check supported versions!!
Steps to perform as recommended by VMWare Support
Using a new VirtualCenter installation with a new database and preserving existing Lab Manager configurations and templates
Provision or reserve storage that is available to Lab Manager for backup.
Undeploy all active configurations and virtual machines.
Export each configuration to the storage in step 1.
Export each library capture to the storage in step 1.
Export each template to the storage provisioned in step 1.
If you have installed Lab Manager to a virtual machine, take a snapshot.
Unprepare the host. Click Resources > Hosts > Disable > Unprepare the host.
Detach the resource pools. Click Resources > Resource pool > Disable > Detach the resource pool.
Power down Lab Manager.
If you have not already done so, create the new VirtualCenter installation.
Unregister your ESX hosts from the old VirtualCenter and register them on the new VirtualCenter.
Recreate the resource pool you had in the old VirtualCenter.
Confirm that the new VirtualCenter installation is functional and power on Lab Manager.
In Lab Manager, click Settings > VirtualCenter and enter the information for the new VirtualCenter.
Note: This includes the IP address, host name, username, and password.
Click Resources > Resource pool > Attach resource pool.
Click Resources > Hosts > Prepare the host.
Import the information that was backed up in steps 3-5.