Inconsistent device naming depending on install method - biosdevname/no biosdevname

[James Page]

After some discussion and debugging in the #juju channel today, we hit upon an issue between the different install types in MAAS; specifically the traditional d-i based install (default in 1.5.x) ends up with biosdevname installed, and the fast-path install does not.

This results in the same physical hardware having different naming for its network interfaces - em1 or eth0 depending on whether biosdevname is installed or not.

This is all technically correct, but not consistent so trips people out - specifically a machine with biosdevname installed ends up with a juju-br0 which is not wired to the outside world, as juju uses the commissioning data in MAAS, which was done without biosdevname so is ethX not emX.

Switching to the fast installer resolves this problem, but it highlights a problem that MAAS and Juju need to deal with.

[Dimiter Naydenov (dimitern)]

The problem in such cases is juju has little control on how the machine's hardware (as seed by lshw) changes between commissioning and deployment, and frankly neither has maas.

jamespage suggested that juju could "inject" a script very early (e.g. a bootcmd) in the cloud-init userdata to try and discover what interface names and MAC addresses the machine has and try to match those from the lshw data juju already gets from maas during node allocation. This nice thing about this solution is that it's not maas specific, but can be used elsewhere (e.g. other distros, with systemd, etc.).

[James Troup (elmo)]

Please also bear in mind that biosdevname, even if installed, can be disabled by a kernel command line argument (i.e. please don't hardcode either an assumption of biosdevname naming based on package presence, or any sort of hard dependency on biosdevname naming).

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Blake Rouse (blake-rouse)]

With the new networking work in MAAS the idea was to create udev rules for all interfaces so the naming is always the same from commissioning to deployment.

I believe this would also fix this issue. Is my assumption correct?

[Dimiter Naydenov (dimitern)]

Blake, yes that's correct - having stable names based on udev rules, especially discoverable via the API will be the proper way to fix this for MAAS. The solution proposed in comment #1 could potentially work for any provider, but relying on networking features (discovery, configuration, even connectivity) during boot is racy and unreliable with current cloud-init support (2.0 will hopefully solve this).

[Lei Wang (raywang)]

I'm also affected by this bug. The name of NIC keeps changing until biosdevname is installed, and remove the /etc/udev/rules.d/70-persistent-net.rules.

This bug makes install hard especially on network naming. and have to tweak curtin with late_command which is very inconvenient.

[Blake Rouse (blake-rouse)]

Curtin now write the udev rules in MAAS 1.9 using the name of the interface set by commissioning or set by the user. The names will be consistent across deployments.

D-I is not longer support is not something that should be used any more.

[Lei Wang (raywang)]

I see the names are consistent across MAAS UI and deployment. However, during the commissioning stage, I guess the biosdevname is not installed, so the names on MAAS are all ethX, so after the system are provisioned, the names in the OS are all ethX. I would rather see emX and pXpX instead.

I run into a problem that i use bonding with ethX (as it is ethX in OS). and the mac address of ethX was changed, so bonding fails. I bet if i use emX naming, that shouldn't be a problem?