Add both `attached` and `connected` properties to NIC devices

[tokred]

Is there an existing issue for this?

• There is no existing issue for this feature

What are you currently unable to do

Context: I am migrating to an Incus- and OVN-based cluster where the central router/firewall will be running in a container on said cluster. To connect existing network-wide VLANs, I am leveraging (unmanaged) bridges with tagged interfaces configured on the cluster nodes.

To prepare and test migration steps, I realized it would be beneficial to allow adding and configuring nic devices to containers/VMs but keep them in a disconnected state from the actual network. This would allow the device to appear in the container/VM but not (yet) being connected to the physical network.

Proxmox has a link_down parameter for NICs which disables connectivity on hypervisor-level, and I think the same functionality would be great for Incus too. This would also be benefical to temporarily disconnect a NIC without having to delete any container config, avoiding workaround like moving the NIC to a placeholder bridge or similar.

What do you think would need to be added

Adding a new boolean config parameter like connected to nic devices, and based on this, connect or disconnect the NIC to the configured parent/network.

[bensmrs]

The approach we’ve taken with other device types is an attached boolean, which effectively removes the device from the guest. That said, nothing really prevents you to configure a non-existing interface. Wouldn’t that be enough for you?
The connected bit could probably be implemented with QMP’s set_link so that could be very easy.
I can take this one for the next milestone.

[tokred]

@bensmrs, I was not aware of the attached parameter (for disks), thanks for the reference! As you mentioned, it does remove the device from the guest though, so a slightly different approach.

What I would love to see for NICs is a "link down" like a hypervisor-controlled "cable plugged" property, because that would allow to a) prepare the entire config on Incus-side, and b) prepare the guest-side network configuration because the NIC device is already available in the guest. But not yet connected to any actual network, so avoiding interference. Further, it would allow to temporarily disconnect a NIC from its network for e.g. troubleshooting, without having to remove the entire device.

Let me experiment with your idea of configuring a non-existing interface, as a workaround! Thanks

[tokred]

Regarding non-existing interfaces, at least bridged NICs perform strict checks:

 » incus config device add fw1 eth1 nic nictype=bridged
Error: Invalid devices: Device validation failed for "eth1": Invalid value for device option "parent": Required value

 » incus config device add fw1 eth1 nic nictype=bridged parent=none
Error: Failed to start device "eth1": Parent device "none" doesn't exist

I may have misunderstood your workaround though?

[bensmrs]

Nah I meant configuring on your guest. At least with networkd, you can configure a non-existing interface.
But it may be harder on some systems.

[stgraber]

@bensmrs rephrased that one to cover both attached and connected, let me know if you want me to assign it to you.

A couple of notes:

• connected for containers can only work with bridged type networking
• connected for containers should control the operstate of the host side veth device. The container will still see the link as up but no traffic will make it through.

[bensmrs]

Alright. No idea how to implement that for containers yet as I’m more knowledgeable about QEMU but that’ll make me learn.
You can assign me this one, yes.

[stgraber]

@bensmrs let me know if you get stuck on the container stuff, but it shouldn't be too difficult as we have a volatile key giving us the name of the host side device, then it's just a matter of getting our internal/server/ip package to let us control OperationalState on that device it doesn't already. We can set it to down during setup and then flip it to up when modified, no real interactions needed with LXC as we're just messing with host-side devices.

[bensmrs]

Oh ok hence the (rather big) limitation on network kinds, which would be nice to lift one way or another.