Breadcrumb Build – VMware HCX from VxRack SDDC to VxRail – Part 3: Conclusion

Welcome to Part 3 of my VMware HCX Breadcrumb Build Series

• Part 1: Preparation
• Part 2: Configuring HCX
• Part 3: Conclusion

HCX pretty much does what it says on the tin, and is pretty straight forward to get running. Some observations below:

• You will need access to the internet. Dark sites might struggle a wee bit, as the HCX appliances need to reach out to a couple of VMware sites to both activate and update….and there is no published way to bypass the online activation process that I’ve found. I know that one of the primary use cases is migration to the public cloud, but it would be good to see some form of offline line activation process for those that want to use it purely internally.
• May need to add HCX appliances to Firewall Exclusion list if you have a locked down NSX Distributed Firewall (DFW). This is true for the management domain of a VxRail under VVD, so if you can’t access the admin interface after deployment the the DFW exclusions should be the first thing you check
• At time of writing, The HCX documentation doesn’t seem to mention certificates. In my experience
  • there is a need to have trusted certs between the endpoints. This may work OOTB if the endpoints share a common trusted root, but even then the installation of those certs on the appliances is not mentioned at all. If you don’t have a common trusted root available (as was the case I tested) then you need to do some additional work to generate self-signed certs and install them before you will be able to establish tunnels between the HCX endpoints
  • there is a need for the destination system to trust the certificate authority used by the source system in order to successfully register the gateway hosts
• With both VVD on VxRail and VxRack SDDC there are multiple vCenters per SSO domain. HCX source (Enterprise) needs to be deployed per desired source vCenter, and once per target vCenter too. Though a single target can accept multiple inbound sources.
• VMware Enhanced vMotion Compatibility (EVC) could play a key part in the success of your vMotion migrations under HCX. CPU compatibility is critical. Both source and target systems will need VMware EVC enabled unless the processor type between them is directly compatible and the source EVC setting should not be higher than the target EVC setting or vMotion will potentially fail.
  • VxRail Manager appears to require a minimum EVC setting of ‘Ivy Bridge’ which may be relevant when configuring. While its unlikely that you will be migrating the VxRail manager, it might influence the level you set your EVC to.
  • Bear in mind that if EVC needs to be configured or lowered, then all VMs in that cluster will need to be powered off to make the change. Increases in level can be made without powering off VMs.
• Performance seems good. A 16MB VM took 4mins to vMotion. A 32GB one took 7 mins. So the data transfer times were good (disclaimer, both sets of kit were in the same lab).

Thats it for this series of posts. Hope you found them useful!