Templatize VM interfaces

[candlerb]

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.

[jeremystretch]

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.

[lampwins]

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.

[candlerb]

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.

[darkstar]

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

[candlerb]

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.

[jeremystretch]

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?

[candlerb]

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

[snazy2000]

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

[candlerb]

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]

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.

[jeremystretch]

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.