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 VM 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 VM systems for migration and to help replication processes prepare the disks on the replica VM 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 VMs 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 VMs and SGW in the compute profile.

You must install the HCX Sentinel software on each guest VM requiring migration to enable the guest VM discovery and data replication. After Sentinel is installed, a secure connection is established between the guest VM and the HCX SGW. HCX builds an inventory of candidates for migration as the Sentinel software is installed on the guest VMs.

Using the established connection between the SGW and SDR, replication connections are established between the Sentinel software on the guest VMs and the SDR, with one connection each for control operations and data replication.

An OS Assisted Migration request triggers the following events:

  1. Replication begins a full synchronization transfer to the destination site. The guest VM remains online during replication until the final delta synchronization.

  2. Before the final delta synchronization, the OS Assisted Migration service quiesces the guest VM.

  3. 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 VM reboots during this process.
    Note: When migrating Windows systems, HCX OSAM 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 OSAM software uses an independent software stack residing on a separate disk for the fix-up process. This fix-up boot disk is detached and deleted at the end of the switchover process.
  4. 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.

  5. As the final step in the switchover, the source is powered-off, the migrated replica is connected to the network, and the switchover completes.

    If the source does not power off, an attempt is made to power off the replica VM. If the replica VM 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 VM and the replica remain on, but the replica is not connected to the network. In this case, you enable the NICs manually that are attached to the replica VM using vCenter, power-off source VM (if not already), and power-on Migrated VM.

  6. VMware HCX Manager names the replica VM with the hostname of the source VM.

  7. VMware Tools is installed on the migrated VM and migration completes.

VMware HCX OS Assisted Migration Requirements

  • Supported OS versions:

    Supported OS versions on KVM Hypervisor

    Supported OS versions on Hyper-V Hypervisor

    RHEL 6.x, 7.x (64-bit)

    Windows Server 2012

    RHEL 6.x (32-bit)

    Windows Server 2012R2

    CentOS 6.x, 7.x (64-bit)

    Windows Server 2016

    CentOS 6.x (32-bit)

    Windows Server 2008 R2 (64-bit)

    Ubuntu server 16.04 (32-bit and 64-bit)

    Ubuntu server 18.04 (64-bit)

    Windows Server 2012

    Windows Server 2012R2

    Windows Server 2016

    Windows Server 2008 R2 (64-bit)

  • Linux workload migration limitations:

    • Unsupported filesystems (supported file systems: ext2, ext3, ext4, XFS).

    • Unmounted filesystems (Linux specific).

    • Unknown content with a partition or a block device.

    • Encrypted filesystems.

    • md devices (software RAID).

  • Windows workload migration limitations:

    • No support for syncing logical volume.

    • Only basic MBR and basic GPT disks are supported. Dynamic GPT and Dynamic MBR disks are not supported.

    • Only NTFS formatted volumes are supported. ESP (EFI system partition) with the FAT32 file system is an exception.

    • No support for non-windows service applications relative to system quiescing during the final sync.

    • Systems with more than 64 volumes are not supported since VSS allows a maximum of 64 snapshots on a system.

  • Sentinel software is not automatically updated.

  • An SDR appliance can support up to 57 active replica disks. This support limits the number of VMs that can be migrated at the same time. In other words, the total number of disks among all active migrating VMs cannot exceed 57.

  • Only one SGW and one SDR deployment is supported per Service Mesh, meaning that multi-site service mesh is not supported.

  • Guest VMs can only be migrated to a datastore that is accessible by the SDR.

  • Linux systems: interface bonding and statics routes are not supported.

  • VLAN interfaces on Linux and Windows are not supported.

  • Redeployment of SGW and SDR appliances is not allowed when any migration is in-progress.

  • For Windows systems, in general the pre-requisites for the VMware Tools installation have to be satisfied on the source system. The pre-requisites for the VMware Tools installation can vary based on: the target VC and ESX version, and Windows OS version on the source system. For example, if the target ESXi version is 6.5.0 (or higher), VMware Tools version is 10.3.x. The prerequisites based on different Windows OS versions are listed at: https://kb.vmware.com/s/article/55798.

  • On RHEL/CentOS 7.0, 7.1, and 7.2, the XFS filesystem UUID is not restored to the original UUID for the filesystem where /boot resides because mkfs.xfs does not support the functionality (-m option). A new random UUID is generated. Modifying the UUID after the filesystem is created triggers RHEL bug 1579390.

  • No support for uninstalling a sentinel and delete its associated resources (for example, replica disks, database entries). You can manually uninstall the Sentinel software running on source VM systems by running a script for Linux systems and using built-in uninstall mechanism for Windows systems. Manually delete the associated resources.

  • Linked Mode VCs are not supported.

  • VMC, vCD, and VIO cloud types are not supported.

  • Only "thin" and "thick" disk provisioning types are supported as the disk provision type for the migrated system. The "Same as Source" option is not supported.

  • Datastore Cluster (storage pod) as Destination Storage is not supported.

  • Linux Systems where /boot resides inside a logical volume are not supported. Only Linux systems where /boot resides in a physical partition are supported.

  • /etc/fstab entries for removable media (floppy, CD) are not supported; such entries must be commented-out before migration.

  • Migration from PowerCLI fails to start.
  • When migrating Windows systems, the HCX OSAM service applies only the IPv4 configurations to the migrated system based on source system interface configuration. All the other network settings have the default Windows configuration values.
  • Do not run Windows updates on the source system during a migration. If Windows updates are in progress, the migration result can fail.
  • The configuration files of Linux system services (for example, dhcpd) that reference network interface names are not be modified. You must manually modify these files on the migrated system.