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
Serialize NIC add/remove on the target VM's work job queue
addVmToNetwork() runs directly (no queue) whenever the calling thread is
inside any VM work job:
jobContext.isJobDispatchedBy(VM_WORK_JOB_DISPATCHER)
That check does not care whose work job it is. When several VMs deploy in
parallel into different tiers of a VPC, each VmWorkStart job implements its
tier and calls addVpcRouterToGuestNetwork() -> addVmToNetwork(router, ...).
The check is true (we are in the user VM's work job), so every tier attach
runs orchestrateAddVmToNetwork() on the router directly. Nothing serializes
them:
- concurrent getFreeDeviceId() calls hand the same device id to several NICs
- the colliding PlugNicCommands partially fail, then cleanup and retries
reshuffle device ids differently on each router
- on a redundant VPC the two routers' keepalived configs diverge and VRRP
breaks: FAULT or both PRIMARY
Fix: run directly only when the current work job belongs to the VM being
modified (new helper isRunningVmWorkJobForVm()); otherwise dispatch through
that VM's own work job queue. Apply the same rule to removeNicFromVm() and
removeVmFromNetwork() — the latter always ran directly. Scope
removeVmFromNetworkThroughJobQueue()'s pending-job lookup by network uuid,
like the add path, so removals of different networks do not collapse into
one job. Drop an unused retrievePendingWorkJob() call from
addVmToNetworkThroughJobQueue().
Fixes: #11710
Signed-off-by: Brad House <bhouse@nexthop.ai>
0 commit comments