The OS Assisted Migration service supports a variety of hypervisors and guest operating systems in both Linux and Windows environments with limitations and requirements that are both general and specific to these environments.

General Operating System Considerations

Some service limitations are common to Linux and Windows environments where OS Assisted Migration is deployed.

  • The HCX Sentinel Agents are installed in the guest operating system and automatically make connections to the HCX Sentinel Gateway.

  • Guest virtual machines with the locale and the UI language other than English US are not supported.

  • UEFI-based source systems using legacy BIOS boot mode are not supported.

  • Anti-virus software, or any OS application that is actively accessing file systems, can significantly delay the OSAM switchover phase. It is a best practice to disable these types of applications prior to configuring the OSAM migration.

  • Network file shares are not supported with OSAM Migrations. This includes NFS, SMB, and CIFS, with varying outcomes:
    • Mounted files shares like CIFS may result in migration failures.
    • NFS shares are ignored during the fix-up phase and do not result in migration failure.

Linux Specific Considerations

  • Block devices (partitions) with unrecognized content will not be migrated to the destination.

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

    • Unmounted file systems (Linux specific).

    • Unknown content with a partition or a block device.

    • Encrypted file systems.

    • md devices (software RAID).

  • Statics routes are not supported.

  • VLAN interfaces are not supported.

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

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

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

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

Windows Specific Considerations

  • No support for syncing logical volumes.

  • Basic MBR and GPT disk partitions are supported. Dynamic GPT and Dynamic MBR disks partitions are not supported.

    • 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 the 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 before migration are not usable on the migrated system.

  • VLAN interfaces are not supported.

  • 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. To view the list of prerequisites based on different Windows OS versions see VMware KB 55798.

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

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

  • A Windows source system configured as a failover cluster node is not supported.