How to migrate VCSA to a new host without VMotion

• Author
• Recent Posts

Vladan Seget

Vladan Seget is an independent consultant, professional blogger, vExpert 2009-2021, VCAP-DCA/DCD and MCSA. He has been working for over 20 years as a system engineer.

Latest posts by Vladan Seget (see all)

• How to use VMware vSAN ReadyNode Configurator - Fri, Dec 17 2021
• VMware Tanzu Kubernetes Toolkit version 1.3 new features - Fri, Dec 10 2021
• Disaster recovery strategies for vCenter Server appliance VM - Fri, Nov 26 2021

As pointed out, this post targets only small environments that need to migrate VMware VCSA during maintenance. It can also happen that this host simply died, and you need to replace the hardware and reinstall ESXi.

In any case, I assume that the VCSA virtual machine (VM) is on a shared storage that is accessed by your three (or two) hosts. If you have had your VCSA running from the local storage of the host that died and you have no backup of that VCSA, the situation is a little more complicated. You'd have to first find new hardware, transition the local volume to the new host, boot, find all the local VMs, and then register them back again on this newly installed ESXi. As you can see, this is rather lengthy.

Some environments are very small, so vSphere Essentials as a license is just perfect. However, some admins might still prefer using vSphere Lifecycle Manager for upgrades instead of a simple CLI method. In any case, the environment should have a dedicated backup server—a separate physical server with local volumes.

You can configure the environment with backup and replication software and have not only backups of all your VMs on a separate, dedicated backup server but also a "copy" of your VMs in a standby state on the secondary host in case something goes wrong with the primary host. (I'm assuming here that the environment has only two hosts, and you replicate your VMs to the "opposite" host.)

It is also useful to have backup and replication software when the replication is run on the VCSA VM. In this situation, you have a perfect copy of VCSA on a secondary host, with just the data that are not completely up-to-date. It depends on how often you have to replicate the VCSA VM to the opposite host. Note that you should not use this method when you use the vCenter Server in linked mode, as all VCSA nodes replicate data among one and other.

So having a VCSA on a shared datastore within your environment allows you to use several methods for patching the underlying host, either using vSphere Lifecycle Manager or directly via the command line interface (CLI). Let's have a look at these options.

Method 1—Patch the host via CLI

In my case, this is the more direct and simpler method, and it's less complex as well. You can simply shut down the VCSA VM, then put the host into maintenance mode and upgrade via the CLI command. You don't have to move your VCSA VM anywhere.

Note: The host must be connected to the Internet for this to work. If not, you'll have to head to the VMware patch portal and download the patch to your local hard drive. From there, you'll have to copy it to a datastore visible by your ESXi host.

You must enable SSH on that host. Open System customization and select Troubleshooting options > Enable ESXi Shell > Enable SSH.

Enable SSH and ESXi shells

You'll also need to create a firewall rule to allow the ESXi host to connect to the Internet.

esxcli network firewall ruleset set -e true -r httpClient

Check the online depot and list the current image profile and contained packages:

esxcli software sources profile list -d https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml | grep ESXi-7.0

You will see a list of all ESXi 7.0 versions. Pick the latest one with "tools." The version with "no-tools" does not contain VMware tools packages, and it's used for auto-deploy environments.

Latest ESXi version with VMware Tools

Type this command to update your ESXi for the latest ESXi 7.0U3:

esxcli software profile update -d https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml -p ESXi-7.0U3-18644231-standard

Below is a screenshot from my lab.

Patch ESXi without vCenter via CLI

It will take some time depending on your Internet connection. You should see a message indicating a successful update.

Update of ESXi was successful

Reboot the host to complete the update and exit maintenance mode. Once done, simply power on your VMs.

Method 2—Move the VCSA VM to the other host

If you prefer to use vSphere Lifecycle Manager to patch your environment, you can still continue to do so.

You can move VCSA to the other host by registering the VCSA VM on the second host. You simply find the VMX configuration file in the datastore browser on the second host, register the VCSA VM temporarily on this host, start it up, and use your vSphere Lifecycle Manager as you usually do.

Remediate your host as usual with vSphere Lifecycle Manager

Final words

Patching and maintenance of ESXi hosts in small environments using VCSA is not complicated as such, but requires some additional steps. At the end, you might ask yourself whether you need a vCenter Server or not. In case you're managing a small number of VMs on two hosts in many remote environments, it might not be worth adding a VCSA VM to manage and patch. Additionally, VCSA VM consumes memory, storage, and CPU cycles too, so if you don't necessarily need it, don't use it.

As I mentioned at the beginning, you can easily have 2 Node ESXi environments running where you have a separate shared storage for your VMs. It is often a SAN or NAS box. Then, to back up such an environment, you need a separate physical server with local storage and backup software installed using the local storage as a backup repository.

A virtual machine with backup software running in the same environment is like having all your eggs in the same basket. If anything goes wrong, how do you restore when everything is broken, even your backup server? I've seen so many environments where admins didn't take these questions into account and have their backups on the same infrastructure and not a separate server or location. Having a backup and restore strategy is essential, and as admin, you have to plan for every possible scenario.