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

Templatize VM interfaces #1226

New Issue
Closed
opened 2025-12-29 16:30:13 +01:00 by adam · 11 comments
adam commented 2025-12-29 16:30:13 +01:00
Owner
Copy Link

Originally created by @candlerb on GitHub (Sep 15, 2017).

Issue type

[X] Feature request
[ ] Bug report
[ ] Documentation

Environment

  • Python version: 3.5.2
  • NetBox version: v2.2-beta1

Description

Since there is no equivalent to "Device Types" template for Virtual Machines, this means that when you create a VM it has no interfaces, making it somewhat tedious to assign an IP address to a VM.

Simple suggestion: every VM gets one interface by default, type "virtual", name "default". The latter could be set in configuration.py if you always want it to default to e.g. "eth0" instead.

Originally created by @candlerb on GitHub (Sep 15, 2017). ### Issue type [X] Feature request <!-- Requesting the implementation of a new feature --> [ ] Bug report <!-- Reporting unexpected or erroneous behavior --> [ ] Documentation <!-- Proposing a modification to the documentation --> ### Environment * Python version: 3.5.2 * NetBox version: v2.2-beta1 ### Description Since there is no equivalent to "Device Types" template for Virtual Machines, this means that when you create a VM it has no interfaces, making it somewhat tedious to assign an IP address to a VM. Simple suggestion: every VM gets one interface by default, type "virtual", name "default". The latter could be set in `configuration.py` if you always want it to default to e.g. "eth0" instead.
adam added the status: accepted label 2025-12-29 16:30:13 +01:00
adam closed this issue 2025-12-29 16:30:13 +01:00
adam commented 2025-12-29 16:30:14 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Sep 15, 2017):

First, some context for the reader: Device types exist to represent immutable hardware definitions. For example, a Juniper EX4300-48T has 48 Gigabit Ethernet interfaces. This is true of every EX4300-48T ever made and will not change. So, in NetBox we can create a device type to represent this hardware model, and each device created as an instance of this type will automatically be assigned 48 Gigabit Ethernet interfaces.

This concept doesn't extend to virtual machines, because VMs by their nature are arbitrary: a VM might have one interface or it might have a dozen. So there's no direct analog of device types for VMs.

The issue being raised here is that the user must manually create interfaces for new VMs, which can be tedious. (Interfaces can be created across multiple VMs in bulk, but it's still an extra step in the provisioning process.)

#1364 was raised recently to address the possibility of adding a "deployment template" for devices which extends beyond the hardware definition. I haven't had a chance to dig into that yet, but it seems reasonable to extend that concept to virtual machines as well. It would be nice to support a template which could automatically assign not only interfaces, but set a VMs status and resource attributes as well.

I'll leave this issue open for now, but we might be able to fold it into #1364 at some point.

@jeremystretch commented on GitHub (Sep 15, 2017): First, some context for the reader: Device types exist to represent immutable hardware definitions. For example, a Juniper EX4300-48T has 48 Gigabit Ethernet interfaces. This is true of every EX4300-48T ever made and will not change. So, in NetBox we can create a device type to represent this hardware model, and each device created as an instance of this type will automatically be assigned 48 Gigabit Ethernet interfaces. This concept doesn't extend to virtual machines, because VMs by their nature are arbitrary: a VM might have one interface or it might have a dozen. So there's no direct analog of device types for VMs. The issue being raised here is that the user must manually create interfaces for new VMs, which can be tedious. (Interfaces can be created across multiple VMs in bulk, but it's still an extra step in the provisioning process.) #1364 was raised recently to address the possibility of adding a "deployment template" for devices which extends beyond the hardware definition. I haven't had a chance to dig into that yet, but it seems reasonable to extend that concept to virtual machines as well. It would be nice to support a template which could automatically assign not only interfaces, but set a VMs status and resource attributes as well. I'll leave this issue open for now, but we might be able to fold it into #1364 at some point.
adam commented 2025-12-29 16:30:14 +01:00
Author
Owner
Copy Link

@lampwins commented on GitHub (Sep 15, 2017):

I agree some sort of template for VMs would be of great benefit. It is true that VMs differ from physical devices in a number of ways. However in the real world, I think it is fair to say many (maybe even most) VM deployments are highly templatetized. Again not in the same way we do templates for physical devices today. More along the lines of an application or use case template for the VMs.

@lampwins commented on GitHub (Sep 15, 2017): I agree some sort of template for VMs would be of great benefit. It is true that VMs differ from physical devices in a number of ways. However in the real world, I think it is fair to say many (maybe even most) VM deployments are highly templatetized. Again not in the same way we do templates for physical devices today. More along the lines of an application or use case template for the VMs.
adam commented 2025-12-29 16:30:14 +01:00
Author
Owner
Copy Link

@candlerb commented on GitHub (Sep 15, 2017):

This is true; and if the deployment template feature comes along and can be applied to VMs, so much the better. Being able to "clone" an existing VM or Device is another approach. (#33)

However, the 80/20 rule says that the majority of VMs have a single interface which by definition is virtual (*); so the quick fix of creating one virtual interface may work as a stop-gap.

(*) Aside: I note Virtual Machines provide two interface types, Virtual and LAG. I am guessing this is to allow a VM to have two virtual NICs (e.g. eth0 and eth1) and combine them into a LAG at the VM level, rather than externally at the hypervisor which is where it would be normally done. Seems like an unusual use case to me.

A more common use case is that a VM has one external interface (e.g. eth0) and multiple sub-interfaces (e.g. br100 linked to eth0.100, br101 linked to eth0.101). In this case br100 and br101 have to be represented as additional virtual interfaces. Since they are not a LAG, Netbox won't let me associate br100 and br101 with eth0.

It's not a big problem, but maybe having an interface type like "Subinterface" which can be associated with a parent interface (like a LAG) could be useful.

@candlerb commented on GitHub (Sep 15, 2017): This is true; and if the deployment template feature comes along and can be applied to VMs, so much the better. Being able to "clone" an existing VM or Device is another approach. (#33) However, the 80/20 rule says that the majority of VMs have a single interface which by definition is virtual (*); so the quick fix of creating one virtual interface may work as a stop-gap. ---- (*) Aside: I note Virtual Machines provide two interface types, Virtual and LAG. I am guessing this is to allow a VM to have two virtual NICs (e.g. eth0 and eth1) and combine them into a LAG *at the VM level*, rather than externally at the hypervisor which is where it would be normally done. Seems like an unusual use case to me. A more common use case is that a VM has one external interface (e.g. eth0) and multiple sub-interfaces (e.g. br100 linked to eth0.100, br101 linked to eth0.101). In this case br100 and br101 have to be represented as additional virtual interfaces. Since they are not a LAG, Netbox won't let me associate br100 and br101 with eth0. It's not a big problem, but maybe having an interface type like "Subinterface" which can be associated with a parent interface (like a LAG) could be useful.
adam commented 2025-12-29 16:30:14 +01:00
Author
Owner
Copy Link

@darkstar commented on GitHub (Sep 18, 2017):

I manage storage-VMs in large multi-tenant capable enterprise storage systems and there, every tenant can decide for himself on how he names the virtual interface(s) of his storage VM. There is no pre-defined name. Some call the first interface "mgmt" and the data interface "data", other call them "lif0" and "lif1". Even others don't require a dedicated management interface and might go with just a data interface called "vlan12-data" or something.
So in my case I would welcome a way to disable that feature, should it ever be implemented.

I think the deployment template would be the better way to go here...

@darkstar commented on GitHub (Sep 18, 2017): I manage storage-VMs in large multi-tenant capable enterprise storage systems and there, every tenant can decide for himself on how he names the virtual interface(s) of his storage VM. There is no pre-defined name. Some call the first interface "mgmt" and the data interface "data", other call them "lif0" and "lif1". Even others don't require a dedicated management interface and might go with just a data interface called "vlan12-data" or something. So in my case I would welcome a way to disable that feature, should it ever be implemented. I think the deployment template would be the better way to go here...
adam commented 2025-12-29 16:30:15 +01:00
Author
Owner
Copy Link

@candlerb commented on GitHub (Sep 19, 2017):

There is no pre-defined name. Some call the first interface "mgmt" and the data interface "data", other call them "lif0" and "lif1". Even others don't require a dedicated management interface and might go with just a data interface called "vlan12-data" or something.

To a degree, the same is true of Devices. You might have a Device template with two NICs; however if you install one version of Linux they are called eth0 and eth1, but in a different version of Linux they are enp3s0 and enp3s1. If you install FreeBSD or Windows then they get different names again.

@candlerb commented on GitHub (Sep 19, 2017): > There is no pre-defined name. Some call the first interface "mgmt" and the data interface "data", other call them "lif0" and "lif1". Even others don't require a dedicated management interface and might go with just a data interface called "vlan12-data" or something. To a degree, the same is true of Devices. You might have a Device template with two NICs; however if you install one version of Linux they are called eth0 and eth1, but in a different version of Linux they are enp3s0 and enp3s1. If you install FreeBSD or Windows then they get different names again.
adam commented 2025-12-29 16:30:15 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Sep 20, 2017):

I note Virtual Machines provide two interface types, Virtual and LAG. I am guessing this is to allow a VM to have two virtual NICs (e.g. eth0 and eth1) and combine them into a LAG at the VM level, rather than externally at the hypervisor which is where it would be normally done. Seems like an unusual use case to me.

Agreed. I included the LAG interface type just because it is theoretically possible to aggregate two virtual interfaces, though like you I'm not sure why anyone would do that. Should we ditch the interface type option entirely and just set it to "virtual" for all VM interfaces?

@jeremystretch commented on GitHub (Sep 20, 2017): > I note Virtual Machines provide two interface types, Virtual and LAG. I am guessing this is to allow a VM to have two virtual NICs (e.g. eth0 and eth1) and combine them into a LAG at the VM level, rather than externally at the hypervisor which is where it would be normally done. Seems like an unusual use case to me. Agreed. I included the LAG interface type just because it is theoretically possible to aggregate two virtual interfaces, though like you I'm not sure why anyone would do that. Should we ditch the interface type option entirely and just set it to "virtual" for all VM interfaces?
adam commented 2025-12-29 16:30:15 +01:00
Author
Owner
Copy Link

@candlerb commented on GitHub (Sep 20, 2017):

Sure: I think having only "Virtual" for all VM interfaces would be an improvement.

@candlerb commented on GitHub (Sep 20, 2017): Sure: I think having only "Virtual" for all VM interfaces would be an improvement.
adam commented 2025-12-29 16:30:15 +01:00
Author
Owner
Copy Link

@snazy2000 commented on GitHub (Apr 9, 2018):

+1 on this, its getting very tedious creating VMs having to create all the interfaces manually :(

@snazy2000 commented on GitHub (Apr 9, 2018): +1 on this, its getting very tedious creating VMs having to create all the interfaces manually :(
adam commented 2025-12-29 16:30:15 +01:00
Author
Owner
Copy Link

@candlerb commented on GitHub (Jun 23, 2018):

Another quick-fix solution would be for the Add VM page (/virtualization/virtual-machines/add/) to incorporate the Add Interface form (/virtual-machines/XXX/interfaces/add/), preferably near the top. Then simply typing "eth0" or "eth[0-2]" into a box is all you need to do. If you don't want to add an interface then you leave it blank.

Pre-populating this field with a default value picked up from configuration.py would then be icing on the cake.

@candlerb commented on GitHub (Jun 23, 2018): Another quick-fix solution would be for the Add VM page (`/virtualization/virtual-machines/add/`) to incorporate the Add Interface form (`/virtual-machines/XXX/interfaces/add/`), preferably near the top. Then simply typing "eth0" or "eth[0-2]" into a box is all you need to do. If you don't want to add an interface then you leave it blank. Pre-populating this field with a default value picked up from `configuration.py` would then be icing on the cake.
adam commented 2025-12-29 16:30:19 +01:00
Author
Owner
Copy Link

@candlerb commented on GitHub (Jun 23, 2018):

Related idea: if the CSV import of VMs could add a pseudo-column containing an interface name pattern (e.g. eth[0-2] or "eth0,lo0") you could import VMs and create the associated interface(s) in one pass. [^1]

This would allow you then to import IP addresses and associate them with the correct VM/interface in a second CSV upload.

This is a simple approach, and would work as long as you don't care about importing other interface attributes like MAC address or MTU (#822) [^1]. Once the interface is created, it's not possible to bulk-update existing objects via CSV (#1732).

[^1] The import VM CSV could also have another pseudo-column for MTU. If specified, all interfaces would be created with the same MTU. This is much like the existing Add Interface form, when used with an interface pattern.

@candlerb commented on GitHub (Jun 23, 2018): Related idea: if the CSV import of VMs could add a pseudo-column containing an interface name pattern (e.g. `eth[0-2]` or `"eth0,lo0"`) you could import VMs and create the associated interface(s) in one pass. [^1] This would allow you then to import IP addresses and associate them with the correct VM/interface in a second CSV upload. This is a simple approach, and would work as long as you don't care about importing other interface attributes like MAC address or MTU (#822) [^1]. Once the interface is created, it's not possible to bulk-update existing objects via CSV (#1732). ---- [^1] The import VM CSV could also have another pseudo-column for MTU. If specified, all interfaces would be created with the same MTU. This is much like the existing Add Interface form, when used with an interface pattern.
adam commented 2025-12-29 16:30:21 +01:00
Author
Owner
Copy Link

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

I'm going to close this out as the planned introduction of deployment templates (#1364) will address all of the concerns here and more. A deployment template will, for instance, allow you to specify not only the names of interfaces but also role, platform, resources, etc.

@jeremystretch commented on GitHub (Jun 24, 2019): I'm going to close this out as the planned introduction of deployment templates (#1364) will address all of the concerns here and more. A deployment template will, for instance, allow you to specify not only the names of interfaces but also role, platform, resources, etc.
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
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#1226
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?