VMware recently announced the release of vSphere 6.0 Update 2m , which officially supports the migration tool. Under the cut, the checklist, how to prepare for migration (important verification points), what migration models are there, and what to look for when migrating from 5.5 Windows vCenter to version 6.0



" VSphere domain

» Deployment Models

» Rules for external model migration version 5.5

» Network (in the continuation of the article)

» Windows settings (in the continuation of the article)

» VCenter Server Database (in continuation of the article)

')

Migration is automatically included in the new vCenter Server Appliance 6.0 Update 2, the migration configuration is already available, and the default preservation of critical data from Windows vCenter Server 5.5 is enabled.



If virtual distributed switch (VDS) is used in your vSphere environment, it will migrate automatically without additional actions. If you want to save your configuration history and performance data (statistics, events, tasks) with configurations, there is an option that allows you to transfer this data. Just need to remember - this will increase the time of your migration and the amount of data in your database in the vCenter Server.



I highly recommend using the article from wiki KB 214620 , which will help to assess and show what the migration process will be (how long, what resources will be used, etc.). In this post there is a checklist of what needs to be considered when preparing for the migration, this is related to the vSphere Single Sign-On domain and the vCenter Server deployment model. There are two most important points about the migration tool, which I would like to emphasize.



The first. Not only your migration will be performed, but also the update of version 5.5 (with any updates) to version 6.0 (Update 2). Before migration, check all parts of VMware and all third-party vendor solutions support vSphere 6.0. The procedure for migration and update has not changed since the previous version, but now there is a mechanism that has greatly simplified this process.



The second important point is that you need to make sure that all Windows vCenter Server configurations are already saved. This includes (but not limited to) data and settings: IP addresses, FQDN, UUID, certificates and MoRef IDs. This makes the migration process much easier, since all parts of the structure communicate with the vCenter Server through the UUID authentication standard, and they will be involved after the migration, as it was in the old version. This checklist is a very important part of preparing a painless migration process.

vSphere domain

The golden rule of preparing for any migration and updates: “you need to know your IT infrastructure well”. There are two areas that also need to be focused on - the vSphere Single Sign-On Domain (SSO) and vCenter Server deployment models.



Let's first deal with the SSO domain. In vSphere 5.5, you should be able to join the vSphere SSO domain if you need it. Your only possibility to make such a union is in version 5.5, because in version 6.0 it will be impossible to do this.



In the example below, two different vSphere SSO domains (vSphere.local -1 and vSphere.local -2). The initial goal was to merge these 2 domains into one - vSphere.local, along with all the configurations from 2 domains. This was done because this option for selecting an existing SSO domain was not applied during deployment to the second SSO server.



If you want to merge vSphere SSO domains, you need to do the following before migration:



• Deploy a new external SSO server

• Point the vCenter Inventory Service, Web Client, and vCenter Server Service on the new SSO server

• If you are going from an internal deployment model to an external one, an internal SSO component must be installed.



After the process is complete, your SSO domain will be merged, as shown in the diagram on the right, and you can begin the migration process. During this unifying process, note that there are - vSphere 6.0 SSO maximums . In this guide - details that are important when combining vSphere SSO domain in version 5.5. If you are satisfied with your existing vSphere SSO topology, then you can plan your vCenter Server deployment.

Deployment Models

This is the next important point in the deployment of vCenter Server. Windows vCenter Server 5.5 has two deployment models: simple and custom.



A simple model is included in all vCenter Server services, in one virtual machine. On the other hand, the custom model allows you to split vCenter Server services (SSO, Inventory Service, Web Client, and vCenter Server) into different virtual machines. In vSphere 6.0, the deployment model is simplified thanks to the embedded Platform Services Controller (PSC) component. Now we can manage different services that are distributed across a single vSphere SSO domain. These services include: Single Sign-On (SSO), certificate management, licensing, roles, tagging and categorization, sharing management.



In vSphere 6.0, we also have two deployment models, only now they are called “internal” and “external”. The internal vSphere 6.0 deployment model corresponds to the simple model in version 5.5. This means that all vCenter Server services and the PSC component remain on the same virtual machine. In an external vSphere 6.0 deployment on virtual machines, there is already a PSC component and vCenter. Each component now responds and manages services. The list of recommended topologies for version 6.0 is here .



Among the advantages of the external implementation model, Enhanced Linked Mode can do automatic scaling by adding Enhanced Linked Mode and vCenter Server.



Important! vSphere 6.0 Update 2m - does NOT allow you to change the deployment topology during the migration process.







Rules for external model migration version 5.5:



• Do not keep vCenter Inventory Service on the same virtual machine as the external SSO Server. The internal SSO Server will shut down after the vSphere SSO Service migrates, making the vCenter Inventory Service unavailable.



• When all services are separated (SSO, vCenter Inventory Service, Web Client, and vCenter Server, separately on each virtual machine), you just need to start the migration assistant.



• Migration Assistant will block when all extensions with safe settings are installed on the vSphere SSO Server. The extension with preservation settings - this can be one of the services, such as vCenter Inventory Service, Auto Deploy, and vSphere Authentication Proxy.



• Migration Assistant will signal when extensions without saving the settings will be installed on the vSphere SSO Server. The extension without saving the settings that use the data, but do not store them - vSphere Web Client and Dump Collector.



• Migration of vSphere SSO Servers bypassing the load balancer is available.



VMware got a lot of questions about whether or not to change the vCenter Server deployment model from internal to external, and when to change the deployment model — before or after the migration process. If you do not need to combine SSO domains, then first use the built-in model. After that, use the cmsso command to rebuild and reconfigure your internal model to the external one. More information on using cmsso to change your topology is available here . If you need to combine SSO domains, then your internal model will become external as part of the domain consolidation process. When the merge process is complete, you can begin the migration process. In the migration of external models, first there is a migration of all vSphere SSO servers within the vSphere domain, and then the migration of all vCenter servers. This is no different from the upgrade process.



As noted above, the migration and upgrade process has not changed. There are still a lot of activities that need to be done before starting the migration, but now we have a tool to make the migration process much easier.



A good resource to help you migrate, Migrating vCenter Server 5.5 to vCenter Server Appliance Update 2 FAQ .



And let us know if you managed to migrate or not, you can unsubscribe in the comments or on Twitter using the tag # migrate2vcsa so that VMware tech support can track and respond.



Now we have dealt with different migration models, internal, external for SSO domains and vCenter servers, in the next post in this series we will learn more about Windows vCenter Server.



We took apart the checklist, which is worth paying attention to when migrating, in version 5.5 of Windows vCenter.



UPD

Preparing to migrate vCenter Server to vSphere 6.0 Update 2m. Part 2

---

SIM-CLOUD - Fail-safe cloud in Germany



Dedicated servers in reliable data centers in Germany!

Any configuration, quick build and free installation