The HCX OS Assisted Migration service uses the Sentinel software that is installed on Linux- or Windows-based guest virtual machines to assist with communication and replication from their environment to a VMware vSphere SDDC.
You must install HCX Sentinel on all guest virtual machines requiring migration using HCX OS Assisted Migration. Sentinel gathers the system configuration from the guest virtual machine and assists with the data replication. The source 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.
Sentinel also helps with the data replication by reading data that is written to the source disks and passing that data to the SDR appliance at the destination site.
Guest virtual machines connect and register with an HCX Sentinel Gateway (SGW) appliance at the source site. The SGW then establishes a forwarding connection with an HCX Sentinel Data Receiver (SDR) appliance at the destination vSphere site. You specify the network connections between the guest virtual machines and SGW in the compute profile.
You must install the HCX Sentinel software on each guest virtual machine requiring migration to initate the guest virtual machine discovery and data replication. After Sentinel is installed, a secure connection is established between the guest virtual machine and the HCX SGW. HCX builds an inventory of candidates for migration as the Sentinel software is installed on the guest virtual machines.
Using the established connection between the SGW and SDR, replication connections are made between the Sentinel software on the guest virtual machines and the SDR, with one connection each for control operations and data replication.
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.
