Introduce a separate model for virtual machine interfaces

[jeremystretch]

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.)

[a31amit]

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.

[jeremystretch]

@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.

[a31amit]

@jeremystretch thanks for the confirmation

[jeremystretch]

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

[jeremystretch]

Implemented by PR #4781