HCX 4.0 has just been made GA and is available via the ‘software update’ process within the HCX manager. As you can tell by the ‘4.0’ part, it is no longer following the ‘R’ naming convention. The new version means that this is a major version upgrade and it brings with it a host of new features which will be most welcome for those performing datacentre migrations.
For the keen eyed among you, you’ll notice that the upgrade page shows that the new version is called R148 – this is just cosmetic and is a hangover from existing code.
So, what’s new then?
HCX 4.0 moves aware from the HCX N-3 support approach and version 4.0 will follow VMware’s N-2 support policy. Essentially, HCX 4.0 will be supported for a minimum of 12 months. This is excellent news as it means that frequent upgrades are not required, although still recommended! HCX can also now be found on the VMware Product Lifecycle Matrix and more lifecycle details can be found on the HCX Software and Versioning policies page. It should be noted that HCX 4.0 doesn’t support vSphere 5.X environments – customers using such environments should remain on R147 and engage GSS for supportability options.
When migrations are performed, we have historically been able to edit extended options, such as upgrading the VM hardware, VM tools, generate new SID etc. With version 4.0 this has been extended toe NSX-V and NSX-T tags which will be hugely beneficial for those already using tags and want to continue to do so on their new platform, be it VCF or VMC.
In previous releases, the steps in a migration has always been a bit of an educated guess, with the UI not providing much information. The migration steps are now shown in the GUI, which also exposes a lot of steps of the migration process which were previously hidden. Another inclusion is the estimated time a Bulk Migration will take. This is an excellent addition as it allows those doing migrations to more accurately predict and plan migration events. This also means that if a migration fails, it will show on which specific step the migration failed. This is a huge improvement on previous releases which could be somewhat cryptic with their error messages.
HCX has allowed administrators to extend L2 networks and this has been critical in migration strategies, as a lot of customers simply can’t re-IP their workloads. HCX solves this by allowing layer 2 stretches between datacentre which make migrations a lot simpler. Architecturally HCX has always been difficult when using L2 extension as when a software update is released, there would be downtime involved of around 30 seconds for any network stretches on a given appliance during the upgrade. This has always a sore point with customers as HCX releases cycles have typically been really aggressive, this combined with the support windows makes HCX design decisions difficult. Although not true HA, HCX 4.0 has made a significant improvements in this area and it will deploy a new NE appliance during the upgrade process and switch the L2 traffic over to this new appliance before deleting the old one. What this means is an outage of under a second which is excellent news for our customers. I’m currently working with a customer and we are using HCX to migrate from on-prem to VMC on AWS and the lack of HA for the NE has always been a sticking point, so this news will be most welcome. I’m still in the early stages of testing this and I plan to update this post with my own findings.
Overall HCX 4.0 brings along some most welcome improvements which you would expect with any major version upgrade. I look forward to using it in the field with our customers to enable application mobility.