Recently VMware released vSphere 6.0 Update 2m, an officially supported Migration Tool. The Migration tool will automatically deploy a new vCenter Server Appliance 6.0 Update 2 and migrate configuration, inventory, and alarm data by default from a Windows vCenter Server 5.5. If your vSphere environment is leveraging a virtual distributed switch (VDS), it is part of the configuration and is migrated over by default with no special action needed. If you want to keep your historical and performance data (stats, events, tasks) along with configuration, inventory, and alarm data there is the option to also migrate that information. One thing to keep in mind, this will increase your migration time depending on the data (used size) in your vCenter Server database. I highly recommend using KB 214620 to estimate how long the migration process may take on your Windows vCenter Server 5.5. This blog post will cover a checklist of items to consider prior to starting your migration as they relate to the vSphere Single Sign-On domain and vCenter Server deployment model.
There are two big key items I want to highlight when it comes to the Migration Tool. The first being that not only is there a migration to be performed but also an upgrade by going from version 5.5 (any update) to 6.0 Update 2. Before performing a migration, validate that all current VMware and 3rd party solutions being used will support vSphere 6.0. The planning for a migration or upgrade hasn’t changed from previous versions, but now there is a tool which makes the process a lot easier. Along those lines, the second key item is that the identity of the source Windows vCenter Server is preserved. The identity of the vCenter Server includes, but is not limited to, IP Address, FQDN, UUID, certificates, and MoRef IDs. This makes migrations so much easier since solutions communicate with vCenter Server via UUID, and as far as they are concerned after a migration this is the same old vCenter Server as before. A pre-migration check list is critical piece of your toolkit to ensure you have a pleasant migration journey.
vSphere Domain
The golden rule prior to starting any migration or update is “know thy environment.” Two areas of focus here are the vSphere Single Sign-On (SSO) domain and the vCenter Server deployment models. Let’s first start with the vSphere SSO Domain. In vSphere 5.5, you have the opportunity to consolidate your vSphere SSO domain if you need to. This is your only opportunity to consolidate, because it is not possible in vSphere 6.0.
In the example below, there are two different vSphere SSO domains, vSphere.local -1 and vSphere.local -2. The original goal was to have one vSphere SSO domain, vSphere.local with Linked Mode. This happened because the option of selecting an existing SSO domain was not selected when deploying the second SSO server. If your intention is to consolidate vSphere SSO domains, then the following actions need to take place prior to starting the migration process:
Deploy a new external SSO server.
Repoint the vCenter Inventory Service, Web Client, and vCenter Server Service to the new SSO server.
If going from an embedded deployment to an external deployment, the embedded SSO component will need to be uninstalled.
After this process is complete your vSphere SSO domain will be consolidated, like the diagram on the right, and you may proceed with your migration. While going through this consolidation process, be mindful of the vSphere 6.0 SSO maximums. The following KB provides the details needed to consolidate a vSphere SSO domain in version 5.5. If you are satisfied with your current vSphere SSO topology then proceed with assessing your vCenter Server deployment model.
Deployment Model
The next thing that should be considered is your vCenter Server deployment model. Windows vCenter Server 5.5 has two deployment models, Simple and Custom. A simple deployment includes all vCenter Server services on a single virtual machine. A custom deployment model on the other hand, allows the separation of vCenter Server services (SSO, Inventory Service, Web Client, and vCenter Server) on separate virtual machines. vSphere 6.0 simplified the deployment model by introducing the Platform Services Controller (PSC) component. Now you can manage multiple services that span across a single vSphere SSO domain. These services include Single Sign-On (SSO), certificate management, licensing, roles, tags & categories, and global permissions. In vSphere 6.0 we still retain two deployment models, which are now called embedded and external. The embedded deployment model of vSphere 6.0 equates to the vSphere 5.5 simple install deployment. This means all services making up the vCenter Server and the PSC reside on the same virtual machine. The external deployment of vSphere 6.0 has the PSC component on its own virtual machine and the vCenter Server component on its own virtual machine. Each component now manages the services it’s responsible for. A list of recommended deployment topologies for vSphere 6.0 can be found here. The benefits of having an external deployment are that Enhanced Linked Mode is automatic and ability to scale by adding more PSCs or vCenter Servers. vSphere 6.0 Update 2m does not allow changing your deployment topology during the migration process.
The following are some migration rules for vSphere 5.5 deployment models:
Do not have the vCenter Inventory Service on the same virtual machine as an external SSO Server. The eternal SSO Server will be shutdown after the vSphere SSO Service has been migrated leaving the vCenter Inventory Service inaccessible.
When all services are separated (i.e. SSO, vCenter Inventory Service, Web Client, and vCenter Server are all on separate VMs) you only need to run the migration assistant on the SSO and vCenter Server. The upgrade process will combine the vCenter Inventory Service, Web Client, and vCenter Server components automatically.
The Migration Assistant will error out when stateful extensions are installed on the vSphere SSO Server. A stateful extension is one which stores data, such as the vCenter Inventory Service, Auto Deploy, and vSphere Authentication Proxy.
The Migration Assistant will display a warning when stateless extensions are installed on the vSphere SSO Server. A stateless extension is one which consumes data, but does not store it, such as the vSphere Web Client and Dump Collector.
Migration of vSphere SSO Servers behind a load balancer is supported.
We have received questions on whether it is best to change your vCenter Server 5.5 deployment model from embedded to external before or after the migration process. If you do not have to consolidate your vSphere SSO domain, then migrate your embedded deployment first. Then use cmsso-util to repoint and reconfigure your embedded deployment to an external deployment. More information on using cmsso-util to change your deployment topology can be found here. If consolidation of a vSphere SSO domain is needed, then your deployment will become external as part of the consolidation process. Once the consolidation process is complete you can start the migration process. The order of migration for external deployments is all vSphere SSO Servers within a vSphere domain first, then all vCenter Servers. This is no different than the vSphere upgrade process.
As stated above, the migration or upgrade planning process has not changed. There is still plenty to consider prior to starting, and we just now have a tool to make the migration process a lot easier. A great resource to help you get started with your migration is the Migrating vCenter Server 5.5 to vCenter Server Appliance Update 2 FAQ. Also, please let us know about your migration experience whether good or bad, by leaving comments on this post or on Twitter using the #migrate2vcsa so the team can track and respond. Now that the vSphere SSO domain and the vCenter Server deployment models have been covered, the next blog post in this series will cover the source Windows vCenter Server. There we will focus on a checklist of items you should focus on with your current Windows vCenter Server 5.5 prior to starting a migration.
Recently VMware released vSphere 6.0 Update 2m, an officially supported Migration Tool. The Migration tool will automatically deploy a new vCenter Server Appliance 6.0 Update 2 and migrate configuration, inventory, and alarm data by default from a Windows vCenter Server 5.5. If your vSphere environment is leveraging a virtual distributed switch (VDS), it is part of the configuration and is migrated over by default with no special action needed. If you want to keep your historical and performance data (stats, events, tasks) along with configuration, inventory, and alarm data there is the option to also migrate that information. One thing to keep in mind, this will increase your migration time depending on the data (used size) in your vCenter Server database. I highly recommend using KB 214620 to estimate how long the migration process may take on your Windows vCenter Server 5.5. This blog post will cover a checklist of items to consider prior to starting your migration as they relate to the vSphere Single Sign-On domain and vCenter Server deployment model.
