starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-11 21:10:29 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

Support for Interface Aliases (Alternative Names) on VM and Device Interfaces #10981

New Issue
Open
opened 2025-12-29 21:38:46 +01:00 by adam · 4 comments
adam commented 2025-12-29 21:38:46 +01:00
Owner
Copy Link

Originally created by @ITJamie on GitHub (Apr 4, 2025).

NetBox version

v4.2.6

Feature type

Data model extension

Proposed functionality

Introduce support for defining one or more alternative names (aliases) on both virtual machine interfaces and physical device interfaces. These aliases would reflect how a single interface may be identified differently across contexts—for example, in virtual environments, operating systems, monitoring tools, or provisioning systems.

it should be possible to add or remove multiple alias names per interface

Proposed changes:
• Add a new optional field to both Interface and VMInterface models:
• aliases (JSONField or ArrayField depending on database backend)

Update the UI to:
• Allow users to view and edit aliases on the interface form
• Optionally show aliases in interface list/detail views
Update the REST API to:
• Include the aliases field in interface serializers
• Support filtering by alias (if feasible)

Use case

Interfaces are often known by different names depending on the system or tool involved:
• Virtual machines: net0 (host/qemu) vs. ens18 (guest OS)
• Linux systems: ens18 with altname enp0s18
• SNMP vs. config management tools vs. provisioning systems

Database changes

Add a new optional aliases field to the Interface and VMInterface models:
• Type: JSONField
• use: to hold an Array of strings (e.g. ["ens18", "net0", "enp0s18"])

External dependencies

No response

slack thread

https://netdev-community.slack.com/archives/C01P0FRSXRV/p1743703568159339

Originally created by @ITJamie on GitHub (Apr 4, 2025). ### NetBox version v4.2.6 ### Feature type Data model extension ### Proposed functionality Introduce support for defining one or more alternative names (aliases) on both virtual machine interfaces and physical device interfaces. These aliases would reflect how a single interface may be identified differently across contexts—for example, in virtual environments, operating systems, monitoring tools, or provisioning systems. it should be possible to add or remove multiple alias names per interface Proposed changes: • Add a new optional field to both Interface and VMInterface models: • aliases (JSONField or ArrayField depending on database backend) Update the UI to: • Allow users to view and edit aliases on the interface form • Optionally show aliases in interface list/detail views Update the REST API to: • Include the aliases field in interface serializers • Support filtering by alias (if feasible) ### Use case Interfaces are often known by different names depending on the system or tool involved: • Virtual machines: net0 (host/qemu) vs. ens18 (guest OS) • Linux systems: ens18 with altname enp0s18 • SNMP vs. config management tools vs. provisioning systems ### Database changes Add a new optional aliases field to the Interface and VMInterface models: • Type: JSONField • use: to hold an Array of strings (e.g. ["ens18", "net0", "enp0s18"]) ### External dependencies _No response_ ### slack thread https://netdev-community.slack.com/archives/C01P0FRSXRV/p1743703568159339
adam commented 2025-12-29 21:38:46 +01:00
Author
Owner
Copy Link

@bctiemann commented on GitHub (Apr 7, 2025):

@ITJamie This sounds like an alternative to tagging, but only restricted to interfaces.

  1. Couldn't this be done with tagging?
  2. If implemented, shouldn't this be extended to all models?
  3. One of the reasons I mention tagging is performance considerations. Filtering by tag is performant, but filtering on a JSONField may be less so.
@bctiemann commented on GitHub (Apr 7, 2025): @ITJamie This sounds like an alternative to tagging, but only restricted to interfaces. 1. Couldn't this be done with tagging? 2. If implemented, shouldn't this be extended to all models? 3. One of the reasons I mention tagging is performance considerations. Filtering by tag is performant, but filtering on a JSONField may be less so.
adam commented 2025-12-29 21:38:47 +01:00
Author
Owner
Copy Link

@ITJamie commented on GitHub (Apr 7, 2025):

This has nothing to do with tagging?

Its the fact that interface names can be different depending on the viewpoint. Eg on a linux vm eth0 might have an altname of ens18 or similar.

Similarly that same interface might be known to the hypevisor as a different name (eg net0 in proxmox land)

Its the same logical interface but documenting that it can have alternative names

@ITJamie commented on GitHub (Apr 7, 2025): This has nothing to do with tagging? Its the fact that interface names can be different depending on the viewpoint. Eg on a linux vm eth0 might have an altname of ens18 or similar. Similarly that same interface might be known to the hypevisor as a different name (eg net0 in proxmox land) Its the same logical interface but documenting that it can have alternative names
adam commented 2025-12-29 21:38:47 +01:00
Author
Owner
Copy Link

@bctiemann commented on GitHub (Apr 7, 2025):

Oh I see. Didn't realize this referred to OS-level device aliases, as opposed to aliases for organizing items in NetBox.

@bctiemann commented on GitHub (Apr 7, 2025): Oh I see. Didn't realize this referred to OS-level device aliases, as opposed to aliases for organizing items in NetBox.
adam commented 2025-12-29 21:38:48 +01:00
Author
Owner
Copy Link

@PieterL75 commented on GitHub (Sep 24, 2025):

Isn't a custom field suited for this?

@PieterL75 commented on GitHub (Sep 24, 2025): Isn't a custom field suited for this?
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
beta
breaking change
complexity: high
complexity: low
complexity: medium
needs milestone
netbox
pending closure
plugin candidate
pull-request
Mirrored from GitHub Pull Request
 severity: high
severity: low
severity: medium
status: accepted
status: backlog
status: blocked
status: duplicate
status: needs owner
status: needs triage
status: revisions needed
status: under review
topic: GraphQL
topic: Internationalization
topic: OpenAPI
topic: UI/UX
topic: cabling
topic: event rules
topic: htmx navigation
topic: industrialization
topic: migrations
topic: plugins
topic: scripts
topic: templating
topic: testing
type: bug
type: deprecation
type: documentation
type: feature
type: housekeeping
type: translation
No Label complexity: medium needs milestone netbox status: backlog type: feature
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#10981
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?