vSphere, as a comprehensive virtualization product from VMware, is already in version 7. While carrying out the process of updating significant patches of a given version marked with the letter “u” it is a virtually fully automated process, intuitive, and relatively safe. On the other hand, carrying out an upgrade from a lower to a higher version, on the other hand, is already dependent on many factors.
When to upgrade vSphere?
There are many scenarios and approaches to the vSphere upgrade process itself. VMware’s documentation is more of a signpost than a how-to-do guide. This is mainly due to the fact that vSphere is implemented as a complete solution or is only part of a given infrastructure, and this means that VMware cannot prepare such a document. With such many and different hypervisor implementations from VMware, different companies may want to approach the process in another way. Of course, in any case, the most important thing is to determine the compatibility of the physical components with the new vSphere release.
After the subsequent analysis of our physical servers, it’s time to upgrade, right? Well, not really, because now the point mentioned by VMware in the official documentation should take place, which in my opinion is the most critical point in the entire upgrade operation, i.e., the backup of our virtual infrastructure. VMware backup provided by Xopero ONE allows easy, intuitive, and safe data protection and is perfect for this task. After making sure that we have an up-to-date and validated backup, we are ready to start updating or upgrading our virtual infrastructure.
Updating from previous vSphere version
VMware documentation allows upgrades from previous versions, but in the case of vSphere 7, it must be at least version 6.5. Each previous version is not supported by the upgrade script included in the v7 installer provided by VMware. This itself can be problematic for many companies, but it also shows that reading the manufacturer’s documentation before planning such a process is crucial. Many companies still use vSphere 5.5 as their primary and production virtual environment. This is due to several factors, but one of the significant factors is the vSphere licensing change by VMware that had a place in 2020.
Often, however, the main reason why people are not interested in switching to the latest version of a VMware product is that they decide that what’s new in a newer version is not attractive. I believe this is the wrong approach, and I am explaining why. Each new version is released not only to introduce new features, but also to improve the security of a given product, and as far as I can agree that upgrading vSphere to the latest version on the day of its release may not be the best idea, the newest version with the first major patch should already be taken very seriously as a goal to improve the security of our infrastructure based more or less on a hypervisor from VMware. After the analysis process is completed, whether our physical servers comply with the specification listed in the documentation of the latest version of vSphere, we can proceed to the update process. We use the installation media for this and follow the instructions on the screen.
Rebuild vSphere
It may happen that the company decides not to update, but to install the entire vSphere. I imagine that, for example, in the area of finance and secured internal infrastructures, such an approach makes quite a lot of sense. a separated part of the infrastructure of such an institution may be completely isolated even from the company’s internal network, and thus the installation of vSphere in a higher version than scratch may be safer. Of course, the installation process should be carefully planned.
Installing a newer version of vSphere should be divided into several stages, repeated until you have a fully updated infrastructure. As was the case with the version update described, we should first check the compatibility of components and secure virtual machines and data on them using a backup tool offered by Xopero. Then, if possible, we should move all virtual machines from the host that will be reinstalled first. It is on it that we then install ESXi in a newer version and a new vCenter server.
The next step depends mainly on the version of the infrastructure so far. If it were vCenter version 6.5, the way would be easier, because our new host with vSphere version 7 can manage such hosts. This means that you just need to add the remaining hosts, successively migrate from older hosts. Servers cleaned in this way with older ESXi on board should be disconnected from the farm, reinstalled, and added again.
In case it turns out that the hypervisor we are currently using is lower than 6.5, then we have two paths to choose from. Or first, perform the above-described update of our hosts to version 6.5, or alternatively, export and import virtual machines to the already built vSphere 7, and then reinstall the hosts to vSphere 7 and add successively to the new farm.
In each of these cases, remember to map the network and other settings to the new vSphere. Additionally, it is worth knowing that when disconnecting and reconnecting hosts, templates with the virtual machines will not be automatically added to inventory. You need to search for such a template on the data store and manually add it to the inventory.
Summarizing
I did not describe all the paths, and I do not focus on the process itself, but I hope that this text clearly shows that the issue of having backups, whether physical or virtual (the virtual even more), is a recipe for the so-called peace of mind. Each infrastructure is different, and while each of us assumes that everything will be fine, it is worth having a reliable backup in the event of some unexpected or random issues. Check for yourself that Xopero ONE is exactly the solution for this task. Start your free 30 days trial now.