Virtualbox network adapters pci paths are not predictable

Using an OpenWrt VirtualBox images and adding network adapters is producing non-predictable interface names, I don't know if this is a bug or a misconfiguration on my side but here's how to reproduce it

1 - set up a VM in VirtualBox using the hard disk image provided by OpenWrt
2 - add only one network adapter (intel pro/1000) it doesn't matter if it was a nat or a host-only network anything will do the trick.
3 - after powering on the VM machine you get one interface 'eth0' and if you get it's PCIe path

#Adapter 1: connected to 'eth0'
root@OpenWrt:/# realpath /sys/class/net/eth0/device

this is pretty normal but the problem starts when adding new adapters so turn off the VM and add a second adapter, same settings (intel pro 1000).
4 - You'd expect the first adapter to retain it's interface name 'eth0' and our second adapter should show up as 'eth1' right? well it's not the case what's happening is that the first adapter is being named "eth1" and the second adapter is being named "eth0" and this is probably because the PCIe path for the second adapter has a lower number port than the first adapter.

#adapter1: connected to 'eth1'
root@OpenWrt:/# realpath /sys/class/net/eth1/device
#adapter 2: connected to eth0
root@OpenWrt:/# realpath /sys/class/net/eth0/device

this is very problematic for static network config like in OpenWrt OS especially while testing, I tested this using another Linux based distros and they didn't have the same behavior(probably because they use what's called Predictable Network Interface Names)

Should this be reported as a bug for VirtualBox maintainers or can this be solved from openwrt side ?

What version of VirtualBox are you running?

1 Like

virtualbox version: 6.1.12 r139181
Host OS: manjaro linux

it's fundamentally a VBox issue ( I wouldn't actually call it a bug per-se... ) ...

but the openwrt side of things is an interesting question... as even if virtualbox behaved better... there are similar instances where 'persistent adapter' assignment can be of use...

that said... automating such things is just as much a 'design' and 'philosophy' question as it is a 'practical need' based featureset...

i do see something 'official' happening in this space within the next 12 months... it's a good thing you've brought up one use case here ( you are the second user to post about this behavior here )...

but for now... i'd advise you to deal with it at the VBox level... specifically... the easiest thing being to allocate all nics prior to firstboot..


OpenWrt does not support systemd/udev and unlikely will in the near and distant future.

Ethernet interface enumeration on OpenWrt has always been stable so far for me using qemu (kvm) as hypervisor.

1 Like