Howdy HCX community! I’m a bit later than planned in returning to blogging action. The ‘rona drew my number and threw a wrench into my chaotic house of 8 but I feel back at full strength (enough to press forward), so looking forward to doing just that.
As you may already know VMware HCX 4.3 was released mid-December. If you missed it, here is some related information:
Announcing VMware HCX 4.3
HCX 4.3 Release Notes
HCX 4.3 User Guide
OS Update for OSAM
HCX OS Assisted Migration enables the migration of non-vSphere virtual machines into an HCX enabled cloud. In HCX 4.3, the following operating systems are supported:
- RHEL/CentOS 8.x (64-bit) on KVM
- RHEL/CentOS 8.x(BIOS/GEN-1 & UEFI/GEN-2) on Hyper-V
- Windows Server 2019 Guest OS on KVM and Hyper-V hypervisors.
See the complete table in Supported Guest Operating Systems in the User Guide.
Interoperability with nsx-t 3.2
HCX 4.3 is required when migrating to environments that use NSX-T 3.2 (the mid-December NSX-T release).
RESOLVED log4j vulnerabilities
This release uses a version of Apache Log4j that has resolved the CVE-2021-44228 and CVE-2021-45046 vulnerabilities. For more information on these vulnerabilities and their impact on VMware products, please see VMSA-2021-0028.
Network Extension High Availability (EA)
One of the critical capabilities in HCX is the ability to VERY easily create site to site L2 Network Extension (over the HCX L3 Transport) . With HCX, the operation is abstracted down to a simple right click operation in vCenter Server. While this service has been around for years and is very stable, its achilles heel is the single appliance mode of deployment without a built-in HA mechanism.
With Network Extension High Availability (available with HCX Enterprise), a second appliance is recruited to perform the HA Standby role in each site. The Standby NE appliances run their own transport tunnels, knows the extension configurations, but has a disabled l2 bridging interfaces. In the event of unplanned impact, where the source or destination HA Active appliances become degraded, both the source and destination standby will take over the forwarding function.
Network Extension High Availability uses .5 second heartbeats. Three missed heartbeats will trigger the failure detection workflow.
For comparison an unplanned appliance outage relying on vSphere HA to restart the appliance may experience several minutes of downtime.
Demo – How to Enable Network Extension HA in HCX 4.3
Enabling Network Extension High Availability in HCX 4.3 (14:45)
In this video I ramble a little bit about HA (what it looks like in the UI, and how to enabled it in the product).
Belated end of year and new year greetings from my family to yours!
[…] earlier today, we have several thousand early adopter systems running the HCX 4.3.0 Minor Release (which includes EA for the NE-HA capability). Some conditional issues have been identified, and are resolved in the upcoming HCX 4.3.1 update […]