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

Introduce a separate model for virtual machine interfaces #3753

New Issue
Closed
opened 2025-12-29 18:31:03 +01:00 by adam · 5 comments
adam commented 2025-12-29 18:31:03 +01:00
Owner
Copy Link

Originally created by @jeremystretch on GitHub (Jun 4, 2020).

Originally assigned to: @jeremystretch on GitHub.

Proposed Changes

  • Create a new abstract Interface model to house fields which are common to both device and VM interfaces
  • Update the DCIM Interface model to inherit from the abstract model
  • Create a new Interface model under the virtualization app
  • Update the ForeignKey field on the IPAddress model accordingly

Justification

There are some fields on the current Interface model which don't really apply to virtual machine interfaces, namely mgmt_only and cable. #4615 would introduce a physical label field, which likewise does not apply. Similarly, VM interfaces are restricted to only virtual types. Using a separate model would mitigate the need for special validation when handling VM interfaces. It also greatly simplifies the definition and use of forms, serializers, etc.

There are some downsides to the proposed change that should be pointed out:

  • It will no longer be possible to view all interfaces via a single UI page or REST API endpoint: There will be separate views for device and VM interfaces.
  • The ForeignKey field to the current Interface model on IPAddress will need to be changed. This will presumably be undertaken using separate (ForeignKey fields for the device and VM interface classes, unless we want to revisit multi-table inheritance.)
Originally created by @jeremystretch on GitHub (Jun 4, 2020). Originally assigned to: @jeremystretch on GitHub. ### Proposed Changes - Create a new abstract Interface model to house fields which are common to both device and VM interfaces - Update the DCIM Interface model to inherit from the abstract model - Create a new Interface model under the virtualization app - Update the ForeignKey field on the IPAddress model accordingly ### Justification There are some fields on the current Interface model which don't really apply to virtual machine interfaces, namely `mgmt_only` and `cable`. #4615 would introduce a physical `label` field, which likewise does not apply. Similarly, VM interfaces are restricted to only virtual types. Using a separate model would mitigate the need for special validation when handling VM interfaces. It also greatly simplifies the definition and use of forms, serializers, etc. There are some downsides to the proposed change that should be pointed out: - It will no longer be possible to view _all_ interfaces via a single UI page or REST API endpoint: There will be separate views for device and VM interfaces. - The ForeignKey field to the current Interface model on IPAddress will need to be changed. This will presumably be undertaken using separate (ForeignKey fields for the device and VM interface classes, unless we want to revisit multi-table inheritance.)
adam added the status: acceptedtype: housekeeping labels 2025-12-29 18:31:03 +01:00
adam closed this issue 2025-12-29 18:31:04 +01:00
adam commented 2025-12-29 18:31:04 +01:00
Author
Owner
Copy Link

@a31amit commented on GitHub (Jun 5, 2020):

VM interfaces are restricted to only virtual types. Using a separate model would mitigate the need for special validation when handling VM interfaces.

A VM could have physical interface or devices if it been done through PCI passthrough which makes physical PCI devices not directly seen or used in base hypervisor os but directly in a virtual machine as physical attached and when using scripts or automated discovery inside OS will see those interfaces showed as the physical interface but updates on netbox service might failed if they don't allow physical types of interfaces.

Additionally, if Virtual Machine virtual interfaces can be connected to physical hypervisor device interfaces. In a general production environment, virtual machine interfaces usually tied to the specific physical interfaces of hypervisor so that hypervisor network traffic remains separate from virtual machine network traffic. For a user to know which virtual to the physical path has been taken could help when someone doing troubleshooting and wanted to end-to-end network connection path.

@a31amit commented on GitHub (Jun 5, 2020): >> VM interfaces are restricted to only virtual types. Using a separate model would mitigate the need for special validation when handling VM interfaces. A VM could have physical interface or devices if it been done through PCI passthrough which makes physical PCI devices not directly seen or used in base hypervisor os but directly in a virtual machine as physical attached and when using scripts or automated discovery inside OS will see those interfaces showed as the physical interface but updates on netbox service might failed if they don't allow physical types of interfaces. Additionally, if Virtual Machine virtual interfaces can be connected to physical hypervisor device interfaces. In a general production environment, virtual machine interfaces usually tied to the specific physical interfaces of hypervisor so that hypervisor network traffic remains separate from virtual machine network traffic. For a user to know which virtual to the physical path has been taken could help when someone doing troubleshooting and wanted to end-to-end network connection path.
adam commented 2025-12-29 18:31:04 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jun 5, 2020):

@a31amit what you're describing is outside the scope of this issue. This proposal does not change any of the existing interface types or validation; it is merely for internal purposes.

@jeremystretch commented on GitHub (Jun 5, 2020): @a31amit what you're describing is outside the scope of this issue. This proposal does not change any of the existing interface types or validation; it is merely for internal purposes.
adam commented 2025-12-29 18:31:04 +01:00
Author
Owner
Copy Link

@a31amit commented on GitHub (Jun 7, 2020):

@jeremystretch thanks for the confirmation

@a31amit commented on GitHub (Jun 7, 2020): @jeremystretch thanks for the confirmation
adam commented 2025-12-29 18:31:04 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jun 15, 2020):

Locking as this issue is for some reason generating a lot of off-topic comments.

@jeremystretch commented on GitHub (Jun 15, 2020): Locking as this issue is for some reason generating a lot of off-topic comments.
adam commented 2025-12-29 18:31:04 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jun 24, 2020):

Implemented by PR #4781

@jeremystretch commented on GitHub (Jun 24, 2020): Implemented by PR #4781
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 status: accepted type: housekeeping
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#3753
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?