While HCX design and deployment could easily be a topic for a separate book, let’s point out the most important design decisions to make:
- Consider using AWS DX for migration traffic. You must configure the HCX Service Mesh on the cloud side to use DX. By default, HCX uplinks are mapped to public IPs.
- Consider using Layer 2 extensions to prevent the IP addresses of your application from changing. Consider and discuss the pros and cons of Layer 2 extensions with your networking and security teams (there are a number of security concerns when transmitting Layer 2 broadcast traffic over WAN links).
- Make sure you understand the traffic flow for a VM residing on the Layer 2 extended network. For example, all traffic to an Amazon VPC goes first to your default gateway located on-premises, and after that will be routed back to AWS. The Mobility Optimized Network (MON) feature discussed earlier, in Chapter 3, helps to overcome this issue for traffic between segments within the same SDDC.
- Consider using the RAV migration type, combining the benefits of bulk migration with the ability to live-migrate workloads using vMotion.
- Make yourself familiar with the HCX configuration limitations (for example, no support for migrating a VM with SCSI bus sharing enabled).
- Plan for the future: if you plan to use a Layer 2 extension for a long time, consider enabling high availability for your Layer 2 extension appliance.
- Consider possible VM Virtual Hardware compatibility mismatches between your on-premises and VMware Cloud on AWS, especially when using the i3.metal host type. The per-VM EVC feature may help to overcome this difficulty.
Workload optimization
Moving workloads to VMware Cloud on AWS SDDC does not necessarily mean that the underlying VM configuration is optimized for the service. Depending on your on-premises vSphere configuration and selected options (especially the host type), you may need to perform VM configuration optimization to run efficiently and effectively on VMware Cloud on AWS. We will discuss the most important recommendations based on the main virtual resources: CPU, memory, storage, and networking. We will also touch upon VM management.
CPU
Processors are categorized into families. Typically, processors within the same family have similar sets of features, and processors within the same family and generation support the exact same set of CPU features or capabilities. The CPU capabilities or features available to virtual machines depends on the processor family and generation of the underlying physical hosts.
When virtual machines are migrated from a cluster with one host type to another cluster with a different host type, it is important to understand the vMotion compatibility between both the clusters, and if required reconfigure the virtual machines by enabling Enhanced vMotion Compatibility (EVC). If is also important to understand how vCPUs are presented to your VM:
- Total number of vCPUs
You cannot configure more vCPUs on a single VM than the total number of logical CPUs (including hyperthreaded cores) available on the host. The following table depicts the maximum number of vCPUs on a single VM per instance type:
| Instance Type | Physical/Logical CPU Cores | Max vCPUs per VM |
| i3.metal | 36/36 * | 36 |
| i3en.metal | 48/96 | 96 |
| I4i.metal | 64/128 | 128 |
*Hyperthreading is disabled on i3 hosts
Table 11.1 – Host instance type CPU capabilities