Together with the Sentinel appliances deployed at HCX sites, the HCX OS Assisted Migration(OSAM) service uses the Sentinel software that you install on the Linux- or Windows-based guest virtual machines to assist with communication and replication from their guest environment to a VMware vSphere SDDC.
When OSAM is activated in your Service Mesh, HCX deploys the appropriate Sentinel appliance depending on the Site Pair. For vSphere-based site pairs (multi-site mode), HCX deploys the Sentinel Gateway (SGW) appliance at the HCX Connector (source) site and the Sentinel Data Receiver (SDR) appliance at the HCX Cloud Manager (destination) site. These two appliances work together to migrate workloads from a non-vSphere environment to the VMware SDDC. You also have the flexibility of deploying other service mesh appliances such as WAN Optimization.
For site pairs where the non-vSphere guest environment is paired directly with either a vSphere-based HCX Connector or HCX Cloud Manager site (single-site mode), HCX deploys the Sentinel Resource Gateway (SRG) appliance at the vSphere-based site. This appliance alone handles the migration of the guest workloads from the non-vSphere site to the vSphere-based HCX site.
You must install HCX Sentinel agent software on all guest virtual machines requiring migration using HCX OS Assisted Migration. The software gathers the system configuration from the guest virtual machine and assists with the data replication. The guest system information is used by various HCX OS Assisted Migration service processes. In part, the information is used to create an inventory of guest virtual machine systems for migration and to help replication processes prepare the disks on the replica virtual machine for replication and migration.
After Sentinel is installed, a secure connection is established between the guest virtual machines and the Sentinel appliance. You specify the network connections between the guest virtual machines and Sentinel appliances by configuring the Guest Network Profile setting in the Compute Profile.
HCX builds an inventory of candidates for migration as the Sentinel software is installed on the guest virtual machines.
An OS Assisted Migration request triggers the following events:
Replication begins a full synchronization transfer to the destination site. The guest virtual machine remains online during replication until the final delta synchronization.
Before the final delta synchronization, the OS Assisted Migration service quiesces the guest virtual machine.
The OS Assisted Migration service quiesces the guest virtual machine on a best-effort basis. For example, it is possible for a Linux service running on the guest virtual machine to start immediately after OS Assisted Migration has quiesced the services and stopped all known processes. If some process starts after quiescing the system, it can potentially lead to final synchronization not completing and appear as though the switchover process is stuck.
Note:As part of both continuous and final synchronization, the system checks for changed blocks or files and replicates them.
On a Windows system, the OS Assisted Migration service reads the entire disk to determine the changed blocks to replicate. The process of reading the entire disk can be time consuming.
On a Linux system, the OS Assisted Migration service walks the entire file system to determine the changed files to replicate.
When the delta synchronization finishes, a switchover is triggered. You can have the switchover process start immediately following the initial sync or delay the switchover until a specific time using the scheduled migration option. By using the scheduled migration option, the switchover can occur during a maintenance window. The final delta synchronization begins when the switchover phase starts.
During scheduled migrations, HCX Sentinel performs continuous synchronization by transferring only the deltas since the previous sync cycle. For Windows HCX Sentinel, this synchronization is achieved by identifying the changed file system blocks, whereas for Linux HCX Sentinel this synchronization is achieved by monitoring the changed files. To improve time it takes to reach that final consistency point for Linux systems, a pre-determined set of files and directories listed in /opt/vmware/hcx/osam/excluded_paths is excluded from the continuous synchronization. If you have additional files that do not require monitoring, you can exclude them from continuous synchronization by editing the file. Excluding files requires a restart of the Sentinel service named vmware-hcx-osam-sentinel using service or systemctl commands.
Note:Excluded files are always synchronized to the target virtual machine during the initial and final synchronization phases.
HCX performs a hardware mapping of the replicated volumes to ensure proper operation, including updates of the software stack on the replica. This fix-up process includes adding drivers and modifying the OS configuration files at the destination. The migrated virtual machine reboots during this process.
Note:When migrating Windows systems, HCX OS Assisted Migration software creates a temporary local user on the migrated Windows system during the switchover phase. This user gets deleted after the fix-up process is completed.
Note:When migrating Linux systems, HCX OS Assisted Migration software uses an independent software stack residing on a separate disk, called the fix-up disk, for the fix-up process. To fix-up 64-bit workload VMs, HCX uses the Photon 3.0 64-bit version of the fix-up disk. The fix-up boot disk is detached and deleted at the end of the switchover process.
As the final step in the switchover, the source is powered-off, the migrated replica is connected to the network, and the switchover completes.
The vSphere target virtual machine reboots twice during the switchover phase.
If the synchronization process fails for any reason, such as a broken network connection, by default the synchronization is retried for eight hours. To improve the time it takes to reach a final consistency point for Switchover to begin, you can shorten the retry period to as little as one hour by editing the file /opt/vmware/hcx/osam/etc/sync.params and setting the max_retry_interval from one to eight hours. After setting the interval, restart the Sentinel service named vmware-hcx-osam-sentinel using service or systemctl commands.
HCX Manager names the replica virtual machine with the host name of the source virtual machine.
VMware Tools is installed on the migrated virtual machine and migration completes.
If the source does not power off, an attempt is made to power off the replica virtual machine.
If the replica virtual machine successfully powers off, it remains connected to the NICs. In this case, you can manually power off the source and power on the replica. If the replica does not power off, both the guest virtual machine and the replica remain on, but the replica is not connected to the network. In this case, you activate the NICs manually that are attached to the replica virtual machine using vCenter, power-off source virtual machine (if not already), and power-on Migrated virtual machine.
