You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
VMware NSX network implementation can fail before backing DV port group is visible #13752
On VMware environments using the NSX integration, implementing a guest network can fail during PlugNicCommand even though CreateNsxSegmentCommand has already succeeded.
The NSX segment is created outside vCenter. Its backing distributed virtual port group can therefore take a short time to become visible through the vCenter API. HypervisorHostHelper.prepareNetwork currently performs only one immediate lookup for NSX networks and returns failure when that first lookup is empty.
Sanitized management-server sequence:
CreateNsxSegmentCommand ... NsxAnswer result=true
Prepare network on vmwaredvs <redacted>
Failed to create guest network <redacted>
PlugNicAnswer result=false
The failure rolls back the NIC attachment and prevents the persistent VPC guest network from being implemented.
Versions
Apache CloudStack 4.22.1.0
VMware vSphere / vCenter 8.0.3
CloudStack NSX integration
Steps to reproduce
Configure a VMware zone with the CloudStack NSX integration.
Create an NSX-backed VPC guest network.
Allow the NSX segment command to complete while the backing DV port group is not yet visible through vCenter.
Observe the immediate DV port group lookup fail in HypervisorHostHelper.prepareNetwork, followed by a failed PlugNicCommand.
Expected behavior
After successful NSX segment creation, CloudStack should use its existing bounded DV port group readiness wait before attempting to attach the NIC. If the port group never becomes visible, the existing timeout should still fail the operation cleanly.
Proposed fix
Enable the existing waitForDvPortGroupReady path for NSX broadcast domains and add a regression test covering an empty first vCenter lookup followed by a successful lookup.
On VMware with NSX integration, HypervisorHostHelper.prepareNetwork performs only a single immediate lookup of the NSX-backed distributed virtual port group after CreateNsxSegmentCommand succeeds. Since the NSX segment is created outside vCenter, the DV port group can take a short time to become visible via the vCenter API, causing a race that fails PlugNicCommand and rolls back guest network implementation on VPC tiers.
📊 Assessment
Dimension
Value
Reasoning
Type
type:bug
Race condition/timing bug in NSX network implementation on VMware
Component
component:vmware, component:vpc
Affects HypervisorHostHelper/VMware DVS handling for NSX-backed VPC guest networks
Severity
Severity:Major
Blocks network implementation intermittently, a functional failure with a known code path already available to fix it (existing waitForDvPortGroupReady)
Root cause is precisely identified with file/method names, and a concrete proposed fix (reuse the existing waitForDvPortGroupReady bounded-wait path for NSX broadcast domains, plus a regression test) is already specified
🔗 Similar issues
No closely related open duplicates found.
💡 Notes and suggestions
The proposed fix is well-scoped: enable the existing waitForDvPortGroupReady retry/wait logic for the NSX broadcast domain type in HypervisorHostHelper.prepareNetwork, with a regression test simulating an empty first vCenter lookup followed by a successful one. This looks like a strong candidate for a small, targeted PR.
Activity
boring-cyborg commentedon Jul 30, 2026
Thanks for opening your first issue here! Be sure to follow the issue template!
github-actions commentedon Aug 20, 2026
🎯 Triage report
On VMware with NSX integration,
HypervisorHostHelper.prepareNetworkperforms only a single immediate lookup of the NSX-backed distributed virtual port group afterCreateNsxSegmentCommandsucceeds. Since the NSX segment is created outside vCenter, the DV port group can take a short time to become visible via the vCenter API, causing a race that failsPlugNicCommandand rolls back guest network implementation on VPC tiers.📊 Assessment
HypervisorHostHelper/VMware DVS handling for NSX-backed VPC guest networkswaitForDvPortGroupReady)waitForDvPortGroupReadybounded-wait path for NSX broadcast domains, plus a regression test) is already specified🔗 Similar issues
No closely related open duplicates found.
💡 Notes and suggestions
The proposed fix is well-scoped: enable the existing
waitForDvPortGroupReadyretry/wait logic for the NSX broadcast domain type inHypervisorHostHelper.prepareNetwork, with a regression test simulating an empty first vCenter lookup followed by a successful one. This looks like a strong candidate for a small, targeted PR.Add this agentic workflows to your repo
To install this agentic workflow, run