[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: bullseye64 Vagrant libvirt does not use predictable network names

On Fri, May 14, 2021 at 07:43:05PM +0200, Emmanuel Kasper wrote:
> > i noticed that the bullseye64 Vagrant libvirt box does not use
> > predictable network interface names. It is explicitely disabled with
> > 'net.ifnames=0 biosdevnames=0' in the grub configuration. Is there a
> > special reason doing this? The buster64 libvirt box has predictable
> > names by default. Nowadays non-predictable device names should be used
> > anymore IMO. So i'm wondering why this step back is done in the
> > bullseye64 box.
> Yes the bullseye boxes use the  ethX scheme.
> The reason for that is that we build the same disk image for multiple
> hypervisors (kvm vs virtualbox) and kvm/virtualbox assign the NIC to a
> different position on the PCI bus, which means we cannot configure the
> network beforehand since we don't know what will bethe device name.

One can certainly make the case that naming interfaces based on physical
attributes (MAC addresses, location on the PCI bus, etc) doesn't make
any sense when they very PCI bus they're connected to is just a software
abstraction.  Indeed we're one of the few distros that actually enables
systemd's interface renaming on our cloud VMs, and we've definitely
heard from users that they'd rather we disable it.  So I would
definitely take some issue with the assertion that non-predictable names
should not be used anymore.

> There is code in the git repo (hey Noah !) to handle that situation, which
> injects a ifupdown snippet for every detected NIC via udev,  which is then
> configured by DHCP.
> But unfortunately this conflicts when Vagrant is assigning static IP
> adresses to extra NICs (see
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982356)

Is there no way for us to customize its behavior?  It's fairly common
for a Linux system to run a DHCP client on an attached interface, e.g.
under NetworkManager.  Does Vagrant not provide any mechanism at all to
cope with this behavior?

If we need to, we can identify the first interface by looking at the
index.  Loopback will always get index 1, and the first non-loopback
will get index 2.  In a Vagrant VM, this is *probably* going to be the
interface we want to run DHCP on.  This does not necessarily hold true
elsewhere (especially in containers, but we're not likely running any
DHCP client there.)


Reply to: