VPS migration to the new version - often the “headache” of administrators, but the option “not to switch to the new version” can be fraught with problems in the future. Therefore, we continue to publish useful reviews for everyone who wants to upgrade their virtual machines from 5.5 to 6 version of vSphere.
In the
first part, we talked about preparing for migration for the vSphere Single Sign-On domain and for different vCenter deployment models. Now let's pay attention to two more “stars of our show” - Windows vCenter Server and, of course, Windows vCenter Database.
')
When it comes to Windows vCenter Server, there are immediately a lot of things about the network, accounts, agents, different installed applications, and much more. Like Windows vCenter Server, your data can be pre-evaluated (even before the migration process), how the migration process can take place, which depends on the deployment model (internal / external), and of course, the migration depends on the size of your data. This post focuses on Windows vCenter Server, database and network.
Network
The network is one of the most critical parts of the vCenter Server migration. Before starting the migration, make sure that Windows vCenter Server has the correct DNS configuration and is in place of the forward and reverse lookup zones. Ideally, the vCenter Server is configured as a static DNS, but if there is a need for DHCP support, vSphere 6.0 Update 2m supports this with a slight reservation.
First, make sure your Windows vCenter Server does not use the same IP as your host. In this case, you will not be able to migrate, because this configuration is not supported during the migration through the assistant, and will be blocked while preparing for the migration.
Secondly, if your Windows vCenter Server uses a FQDN with a DHCP address, make sure that everything is reserved, otherwise the migration assistant also blocks this. Also check that the Network Time Protocol (NTP) is enabled and correctly synchronized with the Windows vCenter Server.
When we talk about network configuration when using the vCenter Server, we need to pay attention to user ports. Whatever changes are made, by default, in the vCenter Server ports during the installation process, they will not be confirmed in the migration wizard.
Only configured ports that are supported in ESXi Dump Collector and Auto Deploy will be supported in vSphere web client. Migration occurs through port 9123. If the port is already in use, the next free port will be used, or you can specify the port. In the end, without the condition described below, the migration process will not be successful. You must deploy a temporary IP address in the new vCenter Server Appliance 6.0 while Windows vCenter Server 5.5 is still available.
When the Windows vCenter Server data is collected, the server will shut down and by virtue of the vCenter Server feature that includes the original IP Address - it also migrates. The temporary IP address should be included in the routed network, which is available for our Windows vCenter Server
Windows settings

Windows vCenter Server is the main point during the migration process. Now is the time to conduct a short review of what is already included in the Windows vCenter Server. There may be other applications, parts of applications, agents, scripts, etc. VMware or third-party vendors. Look not only at what is installed on the vCenter Server, also pay attention to what your virtual server uses as the final application. If we store our Windows vCenter Server and all related applications during the migration process, after the migration we will get the same virtual machine as before the migration. There are some applications that may require updating the plug-in or in the case of backups may need some other changes (see below).
In vCenter vSphere 6.0, only image-level backups are supported in both the Appliance Server and Windows. Whether it will be able to migrate or not will depend on whether the vCenter Server is connected to the Active Directory domain, or whether the workgroup or not. If the Windows vCenter Server is connected to an Active Directory domain, then users with credentials should update their accounts on the vCenter server. This
knowledge base tells you what rights users must have in Active Directory in order to upgrade their vCenter Server. Also, remember that since we switched from Windows to Linux, it means that local Windows users and groups do not migrate. This is very important if you use accounts or groups for access rights in the vCenter Server.
One thing needs to be noted: you need to have access to a local account in Windows vCenter Server so that, if necessary, it will be rolled back during the migration process (we will discuss the rollback aspect of migration in more detail in the next review).
Summing up our story about what will NOT be transferred in the process of migration to the new version, I must say that it will NOT be transferred either: any installed agents, antiviruses, monitoring programs, backups, etc. The vCenter Server Appliance doesn’t support anything either. If the vCenter Server is running from under the service account and the account from which the migration is taking place (the migration assistant is running), then you need permission to use the “Replace a process level token” function from an account with Windows security rights. These rights are required for the migration assistant to allow the imitating access token to pass.
Let's look at the solutions that are already installed in the Windows vCenter Server. These applications, authorship of VMware or third-party vendors, will not be available until Windows vCenter Server is turned off. VMware Update Manager (VUM) already includes common applications for users who can install it in the vCenter Server. The migration assistant will mark these installed applications and signal, but continue the migration process, if, of course, you want to continue it. If you need these installed applications after the migration, we strongly recommend installing them on a separate server before the migration process begins.
These migration
instructions will tell you more about installing VUM on an external server.
Another thing that needs to be said about, especially regarding VUM, these application plugins are needed for each individual installation for each user. Make sure that the user who started the migration process has already installed all the plugins needed for the applications, otherwise the migration assistant will give an error. For example, if you started the process of migrating them under a user account that does not have VUM plugins installed, you will get an error.
As mentioned in the first part, we are not only migrating, but also updating. Here are a few points to pay attention to.
- If Linked Mode is configured, the configuration will be deleted even before the migration starts.
- During the migration process, the Windows vCenter Server and vCenter Server Appliance have equal parts at the migration endpoint.
- All vCenter Server certificates are also migrated.
- Any scripts that are stored in the Windows vCenter Server must be moved to another location before the migration begins.
- When the Windows vCenter Server migration is complete, we recommend disconnecting from the network adapter and making sure if the vCenter turns on for whatever reason so that there are no network conflicts.
vCenter Server Database
The vCenter Server database is the “second wing” of Windows vCenter Server. The migration tool supports all sorts of vSphere 5.5 data, from Microsoft SQL (local or remote) to Oracle. The locally installed database will not be available and after migration, while Windows vCenter Server is turned off. vCenter Server 6.0 Update 2m provides the ability to transfer event history and configuration. Just keep in mind that this will increase the time of your migration. To better assess how long a migration will take (with configurations, analytics, event history or, in the variant without them), use a
special script . Depending on the size of the vCenter data, there are also options that help reduce the migration time, but we recommend running the migration assessment script first to see what can happen. One thing will speed up your data in the vCenter Server - it's built-in statistics tools. But they will not work after level 2 statistics, until the error is corrected.
It explains how to use each level of statistics, and when and how they can be used.
If your data in the vCenter Server is a remote SQL or Oracle database, it would be nice to
check if the rollback function works for you and if it is running in the default settings. We always talk about this to our customers who have large databases in the vCenter Server, and they don’t always know if this very necessary rollback function is working (started). After this function is launched in the vCenter Server, their databases are significantly reduced. The next option, which will also help you reduce and clean your database in the vCenter Server, but it is better to use it for very experienced administrators.
If your vCenter Server has not been updated for a long time or has a large database, you may need to
clean your old data . Before you do this, be sure to make sure that you have backed up all the data. These tips may seem annoying, but I insist that all this is best done before the migration and upgrade begins.
If you want to check whether your database is ready for migration, I recommend running the script that estimates the migration time of your data, in order to see not only the time, but also errors that may occur. Also copy the folder with the migration assistant to the Windows vCenter Server and launch it. The assistant can start the preliminary migration preparation and allow you to assess whether your Windows vCenter Server meets all the requirements for migration or whether you need to fix something else. You also have a display of your potential changes - the migration process window.
In the last post in this series, we will talk more about this rollback feature and tasks after the migration is complete.
SIM-CLOUD - Fail-safe cloud in Germany
Dedicated servers in reliable data centers in Germany!
Any configuration, quick build and free installation