Automatically adding detected interfaces to the configuration on Proxmox

Hi all :wave:

I’m planning a video series on using VyOS in a virtualized home lab within Proxmox and one of the things that can trip new users is the lack of the virtual interfaces (added to the VM before installation) in the initial config.

I believe I can recall some bare metal installations detecting those interfaces and adding them, and I’m wondering if there’s a built-in trick to trigger that in general. I plan to develop a script for that if necessary, but was curious if I’m missing something (or am just imagining things from the start!).


1 Like

Hi @eronlloyd,

VM interfaces (e.g. vmxnet3) or any other interface presented to the Linux Kernel on boot will make it into the configuration automatically after installation and first boot.

Imagine a VM with 4 NICs, you will get eth0-eth3 after first boot when installation completed from the ISO.

Hope that helps,

I thought so, but it’s not happening for me in Proxmox VE 7.4-3 (sorry I wasn’t specific). Using the VyOS Rolling from May 21, with the following hardware configured prior to the install:

I’m still seeing this discrepancy:

I’ve also tried the latest LTS with the same results, across three Proxmox instances. This particular instance was just installed yesterday, and is essentially in the out-of-the-box state. It’s clear that the interfaces are being detected and fully present to VyOS (see matching MACs from net0 to eth0):

But during the install I’m getting a bare-bone config:

That is very odd indeed.

Any chance you can contact us on Slack and give us access to that specific environment?

Yeah, sounds like a plan :+1:

@c-po I decided to try the same thing using Juniper vSRX images, and got the same results, so it appears to be more of a Proxmox issue (at least in my case) than VyOS. Using a similar VM setup:


Produces a similar result:

I’ll dig into this further as it could be a bigger platform issue that I’ll need to at least be aware of.

I posted a bug report with Proxmox regarding this issue, and will update this post with updates.


Never get it with Proxmox
Works without any issues

@Viacheslav what PVE version are you? This is what I’m on:

root@pve4:~# pveversion -v
proxmox-ve: 7.4-1 (running kernel: 6.2.9-1-pve)
pve-manager: 7.4-3 (running version: 7.4-3/9002ab8a)
pve-kernel-5.15: 7.4-3
pve-kernel-6.2.9-1-pve: 6.2.9-1
pve-kernel-5.15.107-2-pve: 5.15.107-2
pve-kernel-5.15.102-1-pve: 5.15.102-1
ceph-fuse: 15.2.17-pve1
corosync: 3.1.7-pve1
criu: 3.15-1+pve-1
glusterfs-client: 9.2-1
ifupdown2: 3.1.0-1+pmx4
ksm-control-daemon: 1.4-1
libjs-extjs: 7.0.0-1
libknet1: 1.24-pve2
libproxmox-acme-perl: 1.4.4
libproxmox-backup-qemu0: 1.3.1-1
libproxmox-rs-perl: 0.2.1
libpve-access-control: 7.4-3
libpve-apiclient-perl: 3.2-1
libpve-common-perl: 7.4-1
libpve-guest-common-perl: 4.2-4
libpve-http-server-perl: 4.2-3
libpve-rs-perl: 0.7.6
libpve-storage-perl: 7.4-2
libspice-server1: 0.14.3-2.1
lvm2: 2.03.11-2.1
lxc-pve: 5.0.2-2
lxcfs: 5.0.3-pve1
novnc-pve: 1.4.0-1
proxmox-backup-client: 2.4.2-1
proxmox-backup-file-restore: 2.4.2-1
proxmox-kernel-helper: 7.4-1
proxmox-mail-forward: 0.1.1-1
proxmox-mini-journalreader: 1.3-1
proxmox-widget-toolkit: 3.7.0
pve-cluster: 7.3-3
pve-container: 4.4-3
pve-docs: 7.4-2
pve-edk2-firmware: 3.20230228-2
pve-firewall: 4.3-2
pve-firmware: 3.6-5
pve-ha-manager: 3.6.1
pve-i18n: 2.12-1
pve-qemu-kvm: 7.2.0-8
pve-xtermjs: 4.16.0-1
qemu-server: 7.4-3
smartmontools: 7.2-pve3
spiceterm: 3.2-2
swtpm: 0.8.0~bpo11+3
vncterm: 1.7-1
zfsutils-linux: 2.1.11-pve1

I’ve tried this on six PVEs at this point with no luck using both LTE and Rolling versions:

  • 1 HP Proliant DL360
  • 3 Lenovo Series x3100 M5
  • 2 Netgate (Supermicro) XG-1541

I just also tried using the 6.2 kernel package on the XG-1541s, but still nothing.

Here is what a Proxmox developer is asking in my bug report I opening with them:

[C]ould you try to find out via the vendor support how they detect interfaces?

maybe they have some sort of MAC filter in place and you just need to set a proper MAC prefix on the PVE side? we don’t really do anything “special” with the virtual NICs as they are presented in the VM, the PVE specific parts are all on the host side (e.g., the extra bridge for firewall support and similar things).

I’m happy to help troubleshoot this, as I’d really love to have this working for the start of my VyOS YouTube series, but I don’t know enough about the code base to explain this and experiment with different configurations.

My next thought is to start testing previous 7.x and 6.x PVEs on my hardware and seeing what happens there, too. I’ll begin that while waiting on some input here.

Interfaces with locally administered MAC addresses are not added to the config file automatically during the boot. Such interfaces are considered non-persistent or, more precisely, administered manually.

However, this is not the bug or a problem - they are configurable as real physical interfaces.

Does this nuance generate any real issues for your goals, or are you just curious why the behavior is different from physical NICs? :slight_smile:


Thank you for the insight, @zsdc! That’s definitely something I wasn’t aware of.

So in a nutshell, if the hypervisor (Proxmox, in this case) uses locally administered addresses (LAAs) instead of universally administered addresses (UAAs) from a registered Organizationally Unique Identifier (OUI) for VM interfaces, VyOS will not add those interfaces to the configuration by default.

To work around this, you have to do one of two things:

  1. Manually add each LAA interface to the configuration
  2. Change the LAA prefix of the auto-generated MAC address to use an OUI and (ideally) have the hypervisor use that OUI to generate UAAs in the future

I did some more digging with this insight while trying to figure out why VyOS does generate interfaces on VirtualBox and VMware, and it’s because they own OUIs that generate UAAs. So with this, I changed the default MAC address prefix for Proxmox to use the VMware OUI 00:50:56 and now it works as expected:

So to answer your question, @zsdc, it’s definitely not a real issue, more of a potential stumbling block for new users that could become confused while trying to configure their VyOS VMs. Would it be possible to add a step to the installer to ask whether to add the LAA interfaces to the config? Why would VyOS really care if the interfaces are LAA or UAA?

That was a fun and educational troubleshoot, so thanks for enlightening me. I’m working on some VyOS virtualization home lab documentation, and I’ll share that when it’s done. I’ll also see where in the official docs we could make note of this, as well.


This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.