HCX Network Extension appliance can use a Standard Port Group for its management network

Kaushal, Pravesh 125 Reputation points
2026-06-10T10:47:46.34+00:00

Hi team,

I have a couple of questions regarding our HCX deployment to AVS.

My requirement is to retain the same IP addresses for the migrated workloads in AVS, and I am planning to use HCX Network Extension (NE). Currently, the NE is connected to a Distributed Port Group. Can HCX Network Extension (NE) use a Standard Port Group for its management network while still supporting IP retention for the migrated workloads?

Additionally, I have two on-premises clusters that are managed by the same vCenter Server. In this scenario, do I need to deploy separate HCX components (HCX Connector/Manager, Service Mesh, Interconnect (IX) appliances, and Network Extension (NE) appliances) for each cluster, or can a single HCX deployment manage migrations from both clusters?

Any guidance or best practices would be greatly appreciated.

Regards

PK

Azure VMware Solution
0 comments
Answer accepted by question author
Manish Deshpande 8,135 Reputation points Microsoft External Staff Moderator
2026-06-27T18:35:18.87+00:00

Hi PK,

Thanks for the detailed post — both are great questions that come up quite often in HCX-to-AVS deployments. Let me address them separately.

Q1: Can the HCX Network Extension appliance use a Standard Port Group for its management network while still retaining IPs?

Unfortunately, no this is not a supported configuration. Microsoft requires all HCX service appliances (including the Network Extension/NE appliance) to be connected to a vSphere Distributed Switch (vDS), not a Standard vSwitch or Standard Port Group. HCX relies on advanced vDS capabilities for traffic shaping, network profile management, and QoS — none of which are available on a Standard Switch.

The important distinction here is that there are two separate network requirements at play:

  1. NE appliance management interface → Must be on a Distributed Port Group (vDS-backed). Standard Port Groups are not supported here.
  2. Workload networks being extended (for IP retention) → Must also be backed by a Distributed Port Group or NSX segment. Standard Switch port groups cannot be used as source networks for HCX Network Extension.

Since your NE is already connected to a Distributed Port Group, you're actually already in the right configuration — just keep it there. Don't move the management interface to a Standard Port Group.

One additional callout: if you plan to enable HCX Mobility Optimized Networking (MON) down the line, the Microsoft docs explicitly state that vSphere Standard Switch is not supported for that feature as well.

Configure VMware HCX in Azure VMware Solution – Prerequisites
https://learn.microsoft.com/en-us/azure/azure-vmware/configure-vmware-hcx#prerequisites

Create an HCX Network Extensio
https://learn.microsoft.com/en-us/azure/azure-vmware/configure-hcx-network-extension

Q2: Two on-premises clusters under the same vCenter do I need separate HCX components per cluster?

Great news: No, you do not need separate HCX Connectors or Managers.
HCX has a 1:1 relationship with vCenter Server, so a single HCX Connector can cover all clusters managed by that vCenter. You don't need to deploy duplicate HCX Manager, Interconnect (IX), or NE appliances just because you have two clusters.

What you will need to think about is your Service Mesh and Compute Profile design.

  • If both clusters share the same Management and vMotion networks, you can add both as Service Clusters within a single Compute Profile and a single Service Mesh. The single IX appliance can serve both.
  • If the two clusters have different Management or vMotion network configurations(which is common when clusters are physically or logically separated), the recommended approach is to create separate Compute Profiles and separate Service Meshes one per cluster. This ensures IX and NE appliances are deployed into the correct network context for each cluster.

In both scenarios, one HCX Connector is sufficient on-premises. The Service Mesh (and its appliances) is what scales per cluster not the Connector itself.

Configure VMware HCX – Create a Compute Profile
https://learn.microsoft.com/en-us/azure/azure-vmware/configure-vmware-hcx#create-a-compute-profile

Install VMware HCX in Azure VMware Solution
https://learn.microsoft.com/en-us/azure/azure-vmware/install-vmware-hcx

Compute Profile Considerations and Concepts
https://techdocs.broadcom.com/us/en/vmware-cis/hcx/vmware-hcx/4-10/getting-started-with-vmware-hcx-4-10/hcx-deployment-considerations/compute-profile-considerations-and-concepts.html

Thanks,
Manish.

Was this answer helpful?

1 person found this answer helpful.

1 additional answer

Sort by: Oldest
Most helpful Newest Oldest

  1. AI answer

    2026-06-10T10:48:06.0933333+00:00

    HCX Network Extension (NE) and IP retention

    For retaining IP addresses when migrating workloads to Azure VMware Solution (AVS), HCX Network Extension is the correct mechanism. HCX provides Layer 2 extension so that the default gateway and IP scheme can remain on-premises while VMs are migrated, as described for AVS migrations:

    • HCX Network Extension is used to extend VLAN-backed networks so that IP addresses can be retained across environments.
    • The same HCX L2 extension mechanism is used whether extending from on-premises to AVS or between AVS private clouds.

    The provided material focuses on the need for HCX uplink, management, vMotion, and replication networks and their sizing, but does not specify supportability differences between vSphere Standard Port Groups and Distributed Port Groups for the HCX NE management interface. It only states that:

    • HCX Connector and its appliances require defined management, uplink, vMotion, and replication network segments.
    • These segments must meet the underlay and routing requirements (for example, MTU, reachability, and firewall ports) for HCX IX/NE appliances.

    Because the context does not explicitly distinguish Standard vs Distributed Port Groups for NE management, only the general requirement can be stated: the management network used by HCX NE must satisfy HCX connectivity and routing requirements; IP retention is achieved by L2 extension of the workload networks, not by the specific virtual switch type used for the NE management interface.

    Single HCX deployment for multiple clusters

    For multiple on-premises clusters managed by the same vCenter Server, the context describes HCX at the vCenter/site level:

    • VMware HCX Connector is deployed for the on-premises vSphere environment and uses network profiles (management, uplink, vMotion, replication) defined for that environment.
    • Service Meshes and Network Extension appliances are then created to support migrations and L2 extension between that site and AVS.

    The documentation treats HCX as a site-level mobility platform rather than a per-cluster deployment. It does not require separate HCX Managers/Connectors per cluster when those clusters are under the same vCenter. Instead, it emphasizes:

    • Planning HCX network segments (management, uplink, vMotion, replication) for the on-premises HCX deployment.
    • Ensuring sufficient appliance counts and IP capacity to support the desired number of service meshes and network extenders.

    Therefore, based on the provided information, a single HCX deployment associated with the on-premises vCenter can be used to manage migrations and network extensions for multiple clusters under that vCenter, provided the HCX design (network segments, appliance limits, and service mesh configuration) is sized appropriately.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.