vmware: name mgmt/data-plane interfaces natively for ACOS/TMOS VMs - #4
Merged
Conversation
netbox-device-onboard.py's ACOS/TMOS collectors write interface data using each platform's own native names (e.g. 'ethernet1', '1.1', 'mgmt') and move the vNIC's MAC address onto that interface. netbox-sync's interface matching falls back to MAC address when names don't match, so on its next run it would find that MAC sitting on the differently-named interface, decide that WAS the vSphere-reported vNIC, and rename it back to 'vNIC N (...)' - clobbering the onboarder's data every 5 minutes. Fixes this at the root: for VMs whose already-resolved platform is ACOS or TMOS, name each interface using the vNIC's slot order (slot 1 = mgmt/ management, slot N = the platform's own data-plane naming) instead of the generic 'vNIC N' vSphere label, and skip appending the portgroup/VLAN name suffix for these platforms so the name matches exactly what the other tool looks up. Confirmed via direct MAC cross-check (aXAPI interface/management + interface/ethernet; iControl REST mgmt + 1.N) that vNIC slot order is stable and platform-standard across every A10 vThunder and F5 BIG-IP VE instance in this environment. Verified with a dry-run against production data: zero errors, and every 'attribute name changed' transition is confined to the acos/tmos-platform VMs (thn01a/thn01b already correctly named from prior onboarder testing show no changes at all; bigip-ve-001..007/f50xa/f50xb/ltm01a/ltm01b/ltm02a/ltm02b get a one-time rename to native names). No other VM type is affected.
This was referenced Jul 29, 2026
3 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
mgmt/1.1/1.2... for TMOS,management/ethernet1/ethernet2... for ACOS) instead of the genericvNIC NvSphere label, based on vNIC slot order — confirmed stable via direct MAC cross-check against 4 live VMs (aXAPI + iControl REST).netbox-device-onboard.py's ACOS/TMOS collectors: they move a vNIC's MAC onto a differently-named interface, which caused netbox-sync's MAC-based matching fallback to rename it right back tovNIC N (...)on its next 5-minute run, clobbering the onboarder's data.Test plan
py_compileclean-n) against production vCenter+NetBox: zero errors/exceptionsattribute 'name' changedlines confined to acos/tmos-platform VMs (one-time rename to native names)thn01a/thn01b(already onboarded via the new ACOS collector) show zero changes — confirms convergence, not a fightubuntusrv02) — unaffected, still gets plainvNIC Nnaming