Save to My DOJO
It’s time for yet another migration!
If I had a $1 for every one I’ve done….you know how it goes.
In years past, moving from one vCenter to another was a very tedious task. Most people avoided it at all costs. Normally upgrading in-line was always the best option because maintaining your existing vCenter and building a new one was such a challenge. This meant that if you ran a Windows version of vCenter, you pretty much had to stick with it. This generally made you jealous because you saw how much time VMware had spent developing the vCenter Linux Appliance. You have a lot of different factors to consider and you want to get a migration right the first time. Have you ever removed a host on a distributed vSwitch from vCenter and tried adding it to another? Yea, it doesn’t end well unless you’ve done your homework.
Some of the factors to consider during a vCenter migration:
- The size of your existing environment. Typically, How many hosts/VMs do you have? The bigger the environment, the more challenging the migration will be. It will take longer, the database is larger.
- What type of third party solutions do you have? Are they going to work with the vCSA? You’ll have to take time and test the solutions before the move.
- What type of networks do you have? Are you using standard or distributed virtual switches? With standard switches your configuration is stored on each host, making removing and re-adding them to a different vCenter a breeze. With distributed virtual switches, the configuration is stored on the vCenter and thus, more difficult to move without setting something on fire.
If you’re lucky, you have 10-15 ESXi hosts, are using standard switches and only a few third party tools that interface with vCenter. Your best option would be to build up a new vCSA and move the hosts into the new appliance. All the VMs, networks and individual host configurations would be brought over. However you would lose your long term host performance monitoring data which isn’t ideal and your vCenter permissions will have to be rebuilt. Is that something you really want to lose? Maybe, maybe not.
Other solutions up until now would be to script the process, this has a better success rate vs. manual migrations and it’s a bit easier to do. However, even this method can be a bit tedious and sometimes difficult to troubleshoot, especially if you’re more of a PowerCLI/scripting hacker and didn’t write the script itself! You might get lucky and it will work, but definitely tread with caution!
It’s not all doom and gloom anymore. Here’s the good news.
As of vSphere 6.0 U2m, there is now a tool you can use to help you automate the process. An important thing to remember here is that there was a VMware Fling called VCS to vCSA Converter that was released in 2015, but was recently deprecated. This new tool is not that, it’s a new tool that is officially supported!
But Ryan, why should I go through this hassle to migrate to a Linux Appliance you say? VMware has spent a ton of development time working on the appliance. It’s feature set is equal to a Windows vCenter and the embedded database supports up to 10,000 VMs. If that’s not enough for you, Jason has outlined a comparison blog post so check that out.
I will note that one of the cons was always needing a Windows Box around just to run VUM, that’s been the case up until 6.5. VMware now has VUM integrated into the Linux Appliance. I think this is the point where we burst into tears, yell loudly and clap. Thank you VMware, it has been a long time coming.
So now, we’ve went through the pros and cons, and if you’re still reading this, you’re still wanting to migrate to the appliance. So here goes.
One of the first thing the tool does is deploy a new Linux Appliance and migrates the configuration from your old environment. All of your inventory, alarm data and if you’re using a distributed switch that is brought over. It’s all automatic and done by default! It will ask you if you want to keep things like statistics, events, tasks, along with configuration, inventory, and alarm data so you will have that option. If you decide to keep that data it will increase your migration time significantly. I recommend reading KB 2146420 to help estimate time. The vCenter Server IP Address/Hostname, UUID, MoRef ID, vSphere Tags, Custom Attributes, Folders, Permissions, VDS, Self-Signed/Customer SSL Certificates will all be moved over. This chart was taken from the KB and is a general rule of thumb, however.
For this set of steps, we will make some assumptions that you are currently running vSphere 5.5 U3 with an external SQL database and an external single sign on server and want to migrate to the vCSA 6.0 Update 2M with an external Platform Services Controller. It’s important to remember that at this time, only 5.5 U3 is supported. 5.0 and 5.1 are not supported. You’ll want to upgrade to 5.5U3 if you’re running the older versions. Also, if you are running vSphere 6.0 already on a Windows vCenter, you’re out of luck. At least for now, until they release a newer version. Sometimes it does pay to hold off!
- Copy the Migration Assistant to both the Windows SSO machine and vCenter Server.
- Start the Migration Assistant on the Windows SSO server.
- Migrate the Windows SSO deployment to the vCSA.
- Start the Migration Visitant on Windows vCenter Server.
- Migrate the Windows vCenter Server to vCSA.
Once the migration is complete, you’ll want to re-connect any third party tools you might have had linked to vCenter because the Source Windows vCenter Server hostname\IP address is transferred and the machine is powered off as part of the migration. It’s very similar to VMware Converter. You want to be live at your destination, not your source! Let that old vCenter go happily into the garbage heap.
During the process it will have you change your vCenter Server Inventory name so you’ll want to go back and rename it. I would recommend that before you kick off the migration that you rename your vCenter in the inventory to something like vCenter-old before the move. That way you can just rename it to vCenter or whatever you had it set to initially during the move and keep your life simple.
When you’re finished, kick back and smile.
[the_ad id=”4738″][the_ad id=”4796″]
Not a DOJO Member yet?
Join thousands of other IT pros and receive a weekly roundup email with the latest content & updates!