non-virtio devices get named with systemd "predictable network interface names"

Thank you for taking the time to report this bug and helping to make Ubuntu better. It seems that your bug report is not filed about a specific source package though, rather it is just filed against Ubuntu in general. It is important that bug reports be filed about source packages so that people interested in the package can find the bugs about it. You can find some hints about determining what package your bug might be about at https://wiki.ubuntu.com/Bugs/FindRightPackage. You might also ask for help in the #ubuntu-bugs irc channel on Freenode.

To change the source package that this bug is filed about visit https://bugs.launchpad.net/ubuntu/+bug/1483457/+editstatus and add the package name in the text box next to the word Package.

[This is an automated message. I apologize if it reached you inappropriately; please just reply to this message indicating so.]

Lets get some input from pitti and foundations on how we really shoudl fix this.
At first it looks like "disable that new behavior", but I just want to think that through as we dont want to fight indefinitely.

net.ifnames should be set to 0 by default IIUC[1]. It appears that it's not set in the wily kernel used in this image. I don't know where we configure/control the default value.

We don't see this issue with virtio-net nics because systemd considers virtio numbers to be unstable[2] and doesn't have a rule to name virtio devices (aka the kernel name get's passed through always).

For e1000, this appears in the systemd database and thus gets renamed via the default netrules based on slot location (en, slot 3) -> ens3.

If we append 'net.ifnames=0' to the cloud image as of today and use an e1000 nic, this skips persistent naming and the cloud image boots as expected.

The trouble occurs when we don't have a nic named eth0 due to persistent naming rules triggering and the cloud-image has eth0 embedded into it's filesystem:

% cat /etc/network/interfaces.d/eth0.cfg
# The primary network interface
auto eth0
iface eth0 inet dhcp

1. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762101#105
2. http://lists.freedesktop.org/archives/systemd-devel/2014-July/020908.html

It looks like this is only an issue when a non-virtual nic is presented, i.e. e1000 vs virtio/hyper-v/xenbus/etc. My gut tells me tat 'net.ifnames=0' is the obvious choice as it would maintain ethX regardless of the virtual hardware. But with out some guidance from the foundations team, I am little nervous to make this sort of change (i.e the law of intended consequences)

Pitti, can you weigh in on the correct course of action here?

Wrt. correctly handling multiple interfaces we should IMHO keep the default net.ifnames. After all, providing stable names for cloud instances and virtual machines with multiple interfaces was one of the reasons why we switched to net.ifnames in the first place -- before, the old udev rules had blacklists for all QEMU/HyperV/VMWare/EC-2 etc. interfaces, which meant that while being able to rely on "eth0" was convenient while you had only one interface, this would break down once you add more than one.

So ideally cloud-init (I assume that's what writes interfaces.d/eth0.cfg) would stop hardcoding "eth0" and instead write a configuration for the first (or all, if that's desired) /sys/class/net/en* or /sys/class/eth* that it finds. For multiple interfaces that's semantically equivalent to what we did before (whatever became eth0 got chosen as "the outwards interface we do DHCP on").

For a workaround until this, net.ifnames=0 or overriding 99-default.link is okay as well. But I don't think that's a good long-term strategy.

Please see /usr/share/doc/udev/README.Debian.gz for details.

Martin, can you comment on this in particular?

> net.ifnames should be set to 0 by default IIUC[1]. It appears that it's not set in the wily kernel used in this image. I don't know where we configure/control the default value.

Is it true that net.ifnames is now set to 1 by default in wily? And where is that value set? in systemd/udev binary?

> Is it true that net.ifnames is now set to 1 by default in wily?

Yes, see https://lists.ubuntu.com/archives/ubuntu-devel/2015-June/038786.html and /usr/share/doc/udev/NEWS.Debian.gz and /usr/share/doc/udev/README.Debian.gz .

A nd where is that value set? in systemd/udev binary?

It's the default builtin value, we dropped the patch that sets it to 0.

Thanks Martin.

On Fri, Aug 21, 2015 at 10:39 AM, Martin Pitt <email address hidden>
wrote:

> > Is it true that net.ifnames is now set to 1 by default in wily?
>
> Yes, see https://lists.ubuntu.com/archives/ubuntu-
> devel/2015-June/038786.html and /usr/share/doc/udev/NEWS.Debian.gz and
> /usr/share/doc/udev/README.Debian.gz .
>
> A nd where is that value set? in systemd/udev binary?
>
> It's the default builtin value, we dropped the patch that sets it to 0.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1483457
>
> Title:
> non-virtio devices get named with systemd "predictable network
> interface names"
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+bug/1483457/+subscriptions
>

For the time being this is being addressed with "net.ifnames=0" in the Wily and Xenial images.