Converting VMware vCenters

Transition to VM Squared#

Transitioning from VMware vCenter to VM Squared is straightforward and can be implemented on existing hardware. Even with limited resources the process can be accomplished by incrementally moving a few hosts at a time, migrating VMs in batches to free up resources and repeating.

This article discusses possible ways to locate candidate hosts in your VMware environment and how to transition them to VM Squared while minimizing disruption.

Our plan will be to:

1. Locate candidate vSphere hosts (minumum 3), while:

   • maintaining safe levels of resource availability,
   • avoiding workload disruption, and
   • continuing to provide resilience during migration.

2. Use the candidate hosts to build a VM Squared cluster, which will:

   • enable migration of VMs to VM Squared and
   • provide resilient VM Squared cluster as a migration target.

3. Migrate VMs from vSphere to VM Squared, which will in turn:

   • reduce the resource usage in vSphere

4. Grow the VM Squared cluster by repeating steps 1, 2 and 3 until all the VMs have been migrated onto the VM Squared cluster.

5. Finally, we will be able to shut down our vSphere cluster and have all the hosts managed by VM Squared.

Selecting and removing VMware ESXi hosts#

Identifying ESXi hosts to remove#

Environments in VMware are partitioned into vCenters. Within each vCenter, the hosts are partitioned into clusters.

VMware VMs are assigned to clusters within the vCenter, so the cluster size dictates the availability of CPU and RAM resources.

Smooth running of a VMware environment requires clusters meet VM CPU and RAM demands, as well as provide a safety margin for VMs to reschedule on alternate hosts in the event that a host fails.

VMware recommends a minimum of 3 hosts in each cluster. This means that in larger clusters we can safely remove hosts, depending on the workload levels.

Begin by looking at your available VMware clusters and selecting hosts from those that have spare capacity.

To determine what the workload demands we must look at the current workload usage and the HA Admission Control settings.

1. Measure cluster-wide RAM and CPU allocations using the Cluster performance charts.
   1. Refer to the detailed cluster Memory (MB) chart showing Consumed, Granted and Total memory.
   2. Note cluster CPU usage and make sure it isn’t in the red. This is less important as CPU overcommitment is very flexible.
2. Measure the difference between Granted and Total memory:
   1. Count the difference in per-host units.
   2. For example, with 2048GB total, 896GB consumed and 128GB memory on each host:
      1. 16 host cluster, 7 hosts consumed, 9 hosts spare.
3. Calculate your requirements based on chosen HA policy.
   1. If using Percentage Admission Control take your granted RAM resources and calculate the failover capacity percentage.
   2. If using Slot Policy Admission Control determine your slot size and how many hosts are needed to provide failover slots.
   3. If using Dedicated Failover Hosts Admission Control make sure you have sufficient spare hosts based on current workload.
   4. Determine the lowest number of hosts that could be used to provide your desired failover capacity percentage.
4. HA requirements satisfied, we can now see how many vSphere hosts are surplus to requirements and can be used for migration.
   1. Write a list of these hosts that are surplus to requirements and proceed to the next step.

Removing ESXi - vCenter only#

If your environment uses vSphere with vCenter but without vSAN or NSX, then removing a host is relatively simple.

This process is documented by VMware for vSphere 8 and other versions.

1. Right-click selected host and choose Enter Maintenance Mode.
2. Wait for any VMs to migrate away from the host.
3. Remaining VMs can block maintenance mode.
   1. Ensure vMotion is setup and DRS is enabled.
   2. Check for VMs with mapped USB devices.
   3. Check for VMs with raw disk mappings (RDM).
   4. Check for VMs with CPU Affinity.
   5. On releases earlier than vSphere 7, mapped VM console CD ROM devices could also prevent vMotion.
   6. If in doubt, power off the VMs and temporarily remove CPU Affinity or hardware passthrough devices.
4. Wait for the host to enter maintenance mode.
5. Right-click the host and choose Remove from Inventory.
   1. Select Yes in the confirmation dialogue.

Removing ESXi - vCenter with VSAN#

If you also use VSAN and the host is part of a VSAN cluster, then you should perform a data migration before executing the steps above.

1. When entering maintenance mode you will see an additional option, vSAN data migration.
2. Select Full data migration to safely re-replicate all data on the host’s disks to other hosts.
3. Wait for the host to enter maintenance mode.
4. Right-click the host and choose Remove from Inventory.
   1. Select Yes in the confirmation dialogue.

Removing ESXi - vCenter with NSX or NSX-T#

NSX creates additional API linkages with vSphere and you may need to remove hosts from NSX before removing them from vCenter to ensure a clean uninstall.

• NSX-T provides this article on removing NSX-T hosts from managed hosts.
• NSX provides this article on removing NSX from managed hosts.

Once NSX is removed the hosts can be removed from vCenter or vSAN as described above.

Create a VM Squared deployment#

Follow the steps outlined in Installation to install your first VM Squared hosts and then install at least two more additional hosts for resilience.

VM Squared is now operational and able to act as a destination for your VMware migration.

Catalyst VM migration#

VM Squared is now ready to take VMs from VMware and run them. To migrate the VMs, use the Catalyst migration tool. Deploy Catalyst, then go to the web UI to select VMs for migration. Ensure the VMs are powered off - we will need to convert the VM disks - and begin the migration.

You can run multiple Catalyst instances simultaneously to increase the speed of your migration.

Once the VMs are migrated, start the VMs and validate that items like network configuration are updated and correct.

Do not migrate the VMware appliances such as vCenter and NSX.

Growing your VM Squared environment.#

1. After we have migrated the initial batch of VMs to VM Squared we can remove the VMs and their VMDK files from VMware. This frees resources on the vCenter.

2. We have now reduced the CPU, RAM and disk requirements in the VMware environment and we can repeat the steps to select additional ESXi hosts to transition and add these new hosts to the VM Squared cluster.

3. Now we can select a new batch of VMs to migrate from VMware to VM Squared and go back to Step 1.

1. Once we have a VMware cluster of only 3 hosts, we should try to move all remaining VMs to VM Squared.
2. If you are left with multiple 3-node VMware clusters and do not have sufficient space to migrate, then amalgamate these clusters into a larger VMware cluster:
   • Move the ESXi hosts into the same cluster after ensuring that all ESXi can access all required datastores and networks.

Finalising the conversion#

When the only VMs left in your VMware environment are the VMware Appliances, the last few ESXi hosts can be powered off from their BMC (HP ILO or Dell iDRAC) and re-installed with VM Squared.