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 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 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. 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 14.04 (32-bit and 64-bit)

    Windows Server 2008 SP2 (32-bit and 64-bit)

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

    Ubuntu server 18.04 (64-bit)

    Windows Server 2012

    Windows Server 2012 R2

    Windows Server 2016

    Windows Server 2008 R2 (64-bit)

    Windows Server 2008 SP2 (32-bit and 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:

    • Basic disks (MBR and GPT) are migrated to the destination. Dynamic disks, including logical volumes, are not migrated to the destination.

      • If the boot disk is dynamic, migration is not supported.

      • If the data disks are dynamic, the data on the disks is not migrated, and the disks appear as raw disks on the migrated system.

    • 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 from system quiescing perspective during the final sync.

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

    • Any VSS snapshots present on the source Windows system prior to migration are not be usable on the migrated 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.

  • For Linux systems, interface bonding is only supported for Ubuntu Linux.

  • For Linux systems, 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.

  • 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.

  • OSAM migration service applies the default storage policy to the migrated VMs and their disks. Currently, user selected storage policy is not supported by OSAM service.

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

  • When migrating Windows systems, the 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.

  • When migrating Linux systems, the 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.

  • When migrating Windows systems, the HCX OS Assisted Migration software 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.

  • The configuration files of Linux system services (for example, dhcpd) that reference network interface names are not modified. You must manually modify these files on the migrated system.

  • Do not run Windows updates on the source system during a migration. If Windows updates are in progress, the migration can fail.

  • Source systems with legacy BIOS are not supported. Most UEFI implementations include a BIOS compatibility(legacy) mode.
  • RHEL/CentOS 7.x Virtual Machines running under Hyper-V is supported for both Gen 1/BIOS and Gen 2/UEFI.