Changing the vMotion IP address on a deployed HCX IX (Interconnect) appliance is needed, and editing the existing vMotion Network Profile to remove the currently-leased IP fails with the following error in the HCX Manager UI:
Unable to update IPAM pool with range(s) ##.###.##.### - ##.###.##.###. Some of the affected IPs from the pool are in use.
Running a Service Mesh Resync after editing only the Network Profile pool returns the following result, with no change applied to the IX appliance:
No configuration changes found.
Attempting to create a second vMotion Network Profile pointing at the same vMotion port group is also blocked, because HCX enforces one Network Profile per backing network.
The underlying need to re-IP the IX is typically driven by a duplicate IP on the vMotion subnet. An intermittent vMotion test (failing, then passing) is the common first symptom. The duplicate IP is confirmed by disconnecting the IX vMotion vNIC at the VM hardware level (Edit Settings on the IX VM, uncheck Connected on the vMotion network adapter) and pinging the IX's vMotion IP. A successful ping with the vNIC disconnected proves another device on the subnet is using the same IP.
The HCX internal IPAM holds an active lease on the IX vMotion IP and blocks removal of that IP from the Network Profile pool while the lease is held. Service Mesh Resync compares the deployed appliance state against the Compute Profile / Network Profile binding rather than against pool membership, so a pool-only edit produces no delta for Resync to apply. The HCX one-profile-per-port-group enforcement prevents a parallel vMotion Network Profile from being created on the same port group as a workaround.
Temporarily move the vMotion service in the Compute Profile to a different Network Profile (backed by a different port group, such as the Management or vSphere Replication profile). This releases the lease on the original vMotion IP and allows the original profile to be edited freely. Once the original profile is corrected, move the vMotion service back.
This step must happen before editing the Compute Profile. If the temporary profile has zero free IPs when the Compute Profile is edited and Resync runs, the Resync fails because no IP is available in the pool.
Force Redeploy is not required for this procedure. Resync handles both Compute Profile transitions because changing which Network Profile a service binds to is a configuration delta Resync detects and applies. Force Redeploy is only appropriate as a fallback if a Resync hangs, the IX does not successfully transition between profiles, or the Service Mesh is in a degraded state at the start of the procedure.
If the error persists after following these steps, contact Broadcom Support for further assistance. Provide the following when opening a support request: