The first post of this series covered pre-migration considerations for both the vSphere Single Sign-On domain and vCenter deployment models. Now it’s time to focus our attention on the two co-stars of the show, the Windows vCenter Server and Database. When it comes to the Windows vCenter Server there are plenty of things to consider such as networking, service accounts, agents, and installed applications to name a few. Like the Windows vCenter Server, its database may have some pre-migration considerations depending on whether its is an embedded or external deployment as well as the size of the data being migrated. This post will cover the vCenter Server Windows operating system, database, and network.
Network
One of the most critical pieces to a successful vCenter Server migration is the network. Prior to even starting your migration ensure the Windows vCenter Server has the proper DNS configuration by validating that both forward and reverse lookup are in place. Ideally, vCenter Server should be configured using a static DNS entry, but if there is a reason that requires DHCP, vSphere 6.0 Update 2m does support it with a few caveats. First, make sure that your Windows vCenter Server was not deployed using an IP Address as the hostname. If this is the case you will not be able to migrate because this is an unsupported configuration and the Migration Assistant will fail during pre-checks. Second, if your Windows vCenter Server was deployed using a FQDN along with a DHCP address make sure it has a reservation, otherwise it will also fail during the Migration Assistant pre-checks. Along the same lines, validate that Network Time Protocol (NTP) is in place and syncing correctly on the Windows vCenter Server.
When talking about the vCenter Server network configuration, custom ports need to be part of the discussion. If any changes were made to the default vCenter Server ports during installation, it will not pass the Migration Assistant pre-check validation. There is currently not a supported way to change vCenter Server custom ports back to the default.
The only customized ports that are supported are for ESXi Dump Collector and Auto Deploy which can be found in the vSphere Web Client. The migration process takes place over port 9123. If the port is already in use the next available port will be taken or you can customize to another port of your choosing. Finally, without this next requirement the migration process can not proceed. A temporary IP addresses is needed to deploy the new vCenter Server Appliance 6.0 while the Windows vCenter Server 5.5 is also still available online. Once the Windows vCenter Server data is collected, the server is shutdown and the vCenter Server personality, which includes the original IP Address, is migrated over. The temporary IP Address should be on a routable network that is reachable to the Windows vCenter Server.
Windows Operating System
The Windows vCenter Server will be the biggest focal point during the migration process. Now is the time to go on an expedition to see what is currently installed on the Windows vCenter Server. There could be other solutions installed which includes both VMware and 3rd party applications, agents, scripts, etc. Do not only focus on what is installed directly on the vCenter Server, but what also communicates with it as an endpoint. While we are preserving the personality of the Windows vCenter Server during the migration process, as far as any solution is concerned, once the migration is completed it is the same vCenter Server instance. There will be those solutions that may require a plugin refresh, or in the case of backups may have to change. In vSphere 6.0 both the Windows and Appliance vCenter Server only support image level backups.
The migration process will work whether the vCenter Server is joined to an Active Directory domain or local workgroup. If the Windows vCenter Server is joined to an Active Directory domain, then a user with credentials to update the vCenter Server computer account will be needed. The following knowledge base article covers what user permissions are required to update the vCenter Server computer account in Active Directory. Also, since we are migrating from a Windows operating system to a Linux operating system this means that local Windows users and groups will not be migrated. This is important if you are using accounts or groups for vCenter Server permissions. One thing to note is having access to a local account on the Windows vCenter Server is of benefit in case a rollback of the migration process is required. We will discuss the rollback process in another blog post. Along the lines of what will not be migrated over is any installed agents such as antivirus, monitoring, backup, etc. The vCenter Server Appliance does not support the installation of any agents. Also any service accounts will not be migrated. As part of the migration process, if the vCenter Server service is running under a service account and the account used to run the Migration Assistant is different then the “Replace a process level token” permission is needed under Windows local security. This right is necessary to pass the impersonation token to the Migration Assistant.
Let’s turn our attention to the solutions that are installed on the Windows vCenter Server. These solutions, whether VMware or 3rd party, will no longer be available once the Windows vCenter Server is shutdown. VMware Update Manager (VUM) has been a common solution that customers have installed directly on the vCenter Server. The Migration Assistant will flag these installed solutions and provide a warning, but will allow the continuation of the migration process if you choose. If any of the installed solutions are required after migration, it is recommend to install them on a separate server prior to starting the migration process.
The following section of the migration documentation walks through installing VUM on an external server. One thing worth a mention, especially pertaining to VUM, is if a solution plugin requires a per user installation make sure the user running the migration has that solution plugin installed, otherwise the Migration Assistant throws an error. For example, if you are running a migration and do not have the VUM plugin installed for the user account running the migration, you will receive an error.
As mentioned in the first post of this series we are not only doing a migration but also an upgrade. Here are a few items to keep in mind:
If Linked Mode is configured it will have to be removed prior to starting the migration process.
Migrations have a 1:1 relationship between the Windows vCenter Server and the destination vCenter Server Appliance.
vCenter Server certificates are migrated over.
Any scripts that are stored on the Windows vCenter Server should be moved to another location prior to the migration process.
Once the migration of the Windows vCenter Server is complete, it is recommended to disconnect the network adapter to ensure that if it is accidentally powered on, there is no conflict on the network.
vCenter Server Database
The Windows vCenter Server’s partner in crime is the database. The Migration Tool supports all vSphere 5.5 databases which includes Microsoft SQL (locally or remote) and Oracle. A locally installed database will not be available after the migration process since the Windows vCenter Server is powered off. vCenter Server 6.0 Update 2m gives us the ability to migrate the historical and performance data. Keep in mind this will effect your migration time. In order to get a better estimate of your migration time use the migration time estimation script. This will provide an estimated breakdown of how long the migration will take whether migrating the vCenter Server configuration and inventory or including historical and performance data.
Depending on the used size of the vCenter database there are also options to help reduce migration times but it is recommended to run the migration time estimation script first to see what your potential change control window will look like. One thing that will expedite the growth of the vCenter Server database is using higher statistics internals. The recommendation is not going above level 2 unless there is a debugging issue. The following KB provides an explanation of each statistic level and when they should be used.
If your vCenter Server database is a remote Microsoft SQL or Oracle it is a good idea to check the status of the vCenter Server rollup jobs ensuring that they are running on a regular basis. We have talked to customers who have had a large vCenter Server database and didn’t realize their rollup jobs weren’t running. After running the vCenter Server rollup jobs their database size decreased significantly. The following option will also help reduce the size and cleanup your vCenter Server database but requires an individual with database expertise. If your vCenter Server has been upgraded over the years or has an extremely large database, it may be time to consider purging the old data. Prior to starting the purging process make sure you have taken a backup.
This may seem like a lot to consider, but as I stated prior the migration or upgrade planning process has not changed. If you want to just get a validation of whether or not your vCenter Server and database is ready for the migration process I recommend doing a dry run by running the migration time estimation script to provide not only a breakdown of your database data being migrated but also time required. Also copy the Migration Assistant directory on the Windows vCenter Server and run it. The Migration Assistant will run pre-checks and let’s you know what whether or not your Windows vCenter Server meets all the migration criteria. Together you have an idea of your potential change control window and if anything needs to be corrected prior to migrating your vCenter Server. The final post of this series will cover rollback and post migration tasks.
