HCX Limitation

RiverMeadow

1.

Limited support for non-vSphere- based machines (Physical, Virtual, Cloud) ** OSAM is very limited.

Support for migrations of ANY machine to any native cloud or hybrid cloud.

2. 

Only works to target vSphere environments (AVS, GCVE, VMC, On-prem). For projects going to multi-cloud (VMware vSphere and native public cloud) 2-3 different migration tools may be required (ex. HCX, HCX Migrate, ASR). All with different requirements.

Support for migrations to VMware vSphere (AVS, GCVE, VMC, On-prem) and to public clouds (HCX, Google Cloud or AWS) in a single pane of glass.

3.

Requires Access to Source vSphere hypervisor to deploy virtual appliances.

Does not require access to the Source hypervisor – helpful in “Hostile” migrations; migrating out of existing CSP/Colo or where capacity doesn’t allow on-prem deployments.

4. 

No Support for < vSphere 6.5 

Support for migrations off any source vSphere version.

5.

Conflicts with VMware SRM (vSphere Replication) 

OS-based nor VM-based migrations conflict with VMware SRM or vSphere Replication.

6. 

Large infrastructure footprint required in both Source and Target vSphere environments. Scaling requires multiples of 3 in both source and target.

Tiny infrastructure footprint

7.

Next to no migration telemetry in the product – too much guesswork when planning cutover windows.

Detailed migration telemetry. Plan migration windows down to the minute.

8.

HCX is very slow to replicate data.

RiverMeadow is 10x faster than HCX replicating data as part of migration.

9.

HCX network underlay requirements are not conducive to smaller or unstable networks – IPSec tunnels fail often.

RiverMeadow has been designed from the ground up to handle any network, including those with high latency and low bandwidth.

10.

No fine-tuned control over syncing / target is offline until cutover.

Target is available in isolation for UAT ahead of cutover. Fine-tuned sync allows just files or folders to sync / multiple forms of sync for great flexibility.

11.

No ability to modify virtual hardware as part of a migration.

Ability to change vCPU’s (cores and sockets) and vRAM as part of a migration to right-size workloads moving to cloud.

12.

No ability to resize disks as part of migration.

Ability to resize disks as part of migration to reduce target storage requirement to reduce OPEX in cloud.

13.

No ability to exclude virtual disks as part of migration.

Ability to select which disks to migrate.

14.

No ability to modernize the Operating System as part of migration

Ability to modernize versions of Windows Server starting from 2003 up to 2019 as well as Windows Desktop from 7 to 10 and Redhat 6.x to 7.9. Reduce technical debt as part of migration.

15.

Long list of limitations, including no support for:

• VM’s with DirectPath I/O devices
• VM’s with Shared SCSI bus
• VM’s using vNVME controllers
• VM’s on vVOL datastores

as well as no L2 support for:

• vSphere Standard Switches
• Cisco Nexus / Cisco ASR or any other 3^rd party switches
• vSphere Distributed Switches with LACP configured

RiverMeadow can perform migrations of any source VM and/or VM Network configuration.