HCX Migrations – do not attach NICs to the ‘none’ network at the destination

It came to my attention that there may be a scenario where a VM migrated with HCX can end up on the ‘none’ port group which HCX creates in destination environments. This port group is created by HCX and it is not intended to be used by workload VMs. There may be a situations where VMs being migrated had been connected to legacy networks such as backup or management which are no longer used and therefore require no connection in the destination. Rather than remove these unused NICs it might be tempting to use this ‘none’ port group. Under no circumstances do this as there could be a situation where in a host failure event vSphere HA will not restart these VMs. Please see KB 85788 for further details.

Essentially this network is for use by HCX and the Mobility Agent that it deploys and it is not present on any of the ESXi hosts. While power on, restart and vMotion actions on the VMs will work, it will fail to reboot onto a healthy host in a host failure event as the HA service identifies the network as invalid. Unfortunately the error message in the GUI is a little misleading as it will say insufficient recourses are available.

If you are in a situation where you have legacy networks on VMs which you don’t require in the destination environment then you have a few options available to you:

  • Remove the NICs from the VMs prior to migration. However ensure that they are not required by the underlying OS – some applications license using MAC addresses as an example. Or some older OS types may not like the NIC being removed with the VM running
  • Attach the networks to a valid port group. For example you could create a non-routed NSX-T segment specifically for this scenario
  • Under no circumstances attach the NIC to any HCX layer 2 extended networks which have MON enabled and is already in use by the VM. Although even if disconnected, this will cause a network outage for the VM

It’s frustrating that HCX will validate the ‘none’ port group as a valid destination network during its pre-flight checks. This has been raised with the NSBU and will hopefully be rectified in a future release.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.