F41 Change Proposal: Enable Consistent Device Naming in Cloud Images (self-contained)

Project Discussion Change Proposals
,
1

Enable Consistent Device Naming in Cloud Images

This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.

Wiki
Announced

:link: Summary

This proposal aims to remove the net.ifnames=0 kernel command line entry from the Fedora cloud kickstarts so that consistent device naming is enabled for cloud instances. This change brings Fedora Cloud in line with Fedora Server, Workstation, and CoreOS.

:link: Owner

:link: Detailed Description

Fedora cloud images currently set net.ifnames=0 on the kernel command line during the kickstart process. This disables consistent device naming and ensures that ethernet devices retain the old-style names of eth0, eth1, eth2, and so on.

Removing the net.ifnames=0 configuration allows Fedora cloud instances to use consistent device names for network devices. This brings Cloud images in line with Fedora Server, Workstation, and CoreOS.

:link: Feedback

One of the proposed alternatives is to leave net.ifnames=0 in the kernel command line to remain consistent between releases. Although RHEL allows for net.ifnames=0 for KVM instances, it is recommended not to use it with OpenStack or RHV environments. Fedora Cloud images are used for multiple types of clouds, including public clouds and private clouds.

This approach is less disruptive, but it pushes off the consistent device naming change until a later date and causes cloud images to operate differently than other Fedora deployments.

Other distributions have taken different turns with this configuration. Ubuntu removed it in 2016, Debian added it back in 2017, and SUSE has had it for some time. There were issues with cloud-init during the early days of network device naming in 2016/2017, but cloud-init supports consistent network names since 2017. RHEL currently uses net.ifnames=0, but there is a debate about whether it should be removed in a future major release.

:link: Benefit to Fedora

The main benefit comes from bringing cloud instances inline with other deployment types in how they name network devices. It also helps with cloud providers that offer up different types of network interfaces to an instance. For example, an emulated network device would present itself differently than one offered via SRIOV and it would allow an instance administrator to easily tell which network interface corresponds to each network device. This is especially important for certain clouds, such as OpenStack clouds.

:link: Scope

  • Proposal owners:

  • Other developers:

  • Release engineering: #Releng issue number

  • Policies and guidelines: N/A (not needed for this Change)

  • Trademark approval: N/A (not needed for this Change)

  • Alignment with Community Initiatives:

:link: Upgrade/compatibility impact

Upgrades: Users who are upgrading to the next Fedora release will not notice a change in their instances since the net.ifnames=0 change is only applied during the kickstart process. Their instances will continue using the old network names.

New deployments: If a user has older Fedora deployments and they deploy a new Fedora release with this change applied, their network devices will use consistent network names instead of the old eth0 and eth1 style names. Although this won’t impact software like cloud-init, it will impact users who have deployment scripts (Terraform or Ansible, for example) that need to set network configuration based on the network adapter’s name. They will need to adjust the name of the network device in their deployment scripts.

:link: How To Test

Use an image built without net.ifnames=0 or take an existing cloud instance and remove net.ifnames=0 from the kernel command line:

grubby --update-kernel=current_kernel --remove-args=“kernel_args”

After a reboot, the device names should change from eth0 to reflect the consistent device names based on the hardware:

$ ip link | grep [1] 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 2: enp2s0f0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN mode DEFAULT group default qlen 1000 3: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000 4: enp2s0f1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN mode DEFAULT group default qlen 1000

:link: User Experience

Users who don’t need to apply any specialized network configuration will likely not notice a change. All of the cloud-init functionality will work the same as it did previously.

For users who need to apply specific network configuration on specific instances will need to change the name they use to refer to those network interfaces. For example, the main network device may shift from eth0 to ens3 on some KVM platforms. Other cloud instances might show a network device that specifies a PCI bus entry, such as enp2s0f0. Although this might be confusing at first glance, it will be familiar to users of Fedora Workstation, Server, and CoreOS.

Users could opt out by adding net.ifnames=0 back to their kernel command line:

grubby --update-kernel=ALL --args=“net.ifnames=0”

:link: Dependencies

This change does not depend on any other changes and it has no impact on cloud-specific dependencies, such as cloud-init.

If users have custom setup scripts that apply network configuration, or if they use Terraform/Ansible to perform these steps, they may need to adjust their scripts to account for the new network names.

:link: Contingency Plan

  • Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change)
  • Contingency deadline: N/A (not a System Wide Change)
  • Blocks release? N/A (not a System Wide Change), Yes/No

:link: Documentation

N/A (not a System Wide Change)

:link: Release Notes

  1. 0-9 ↩︎

3 Likes
2

This change proposal has now been submitted to FESCo with ticket #3190 for voting.

To find out more, please visit our Changes Policy documentation.

5

I missed this when first announced, sorry. @mhayden Given that it’s an explicit argument passed to the kernel, what was the reasoning for using net.ifnames=0 in the first place? It was clearly a conscious choice, so what was the original purpose? Was it just because of the cloud-init support not working with it properly before 2017 or was there more to it?

6

I think maybe this might have been my decision back before the dawn of time.

At that point, it wasn’t just cloud-init — pretty much all of the documentation on the web assumed that cloud images would have one network interface, and that that interface would obviously be named /dev/eth0.

Rather than changing all of the Internet, it seemed easier to disable the “predictable” naming.

1 Like
7

Smoking gun: Commit - fedora-kickstarts - e60fa6ff3107e80cb6e2fde7dc4c29fca1810704 - Pagure.io

I think the earlier history is lost to time because there was a separate repo for cloud kickstarts on Fedora Hosted, and we didn’t pull that history in when copying the file to the central fedora-kickstarts repo.

But, in any case, I have no attachment to this choice at this point, and will definitely defer to @mhayden on the right approach here in the year 2024.

1 Like
8

For what it’s worth, the comment

# we don't want to be tied to specific virtual (!) hardware

triggers a dim memory of having a problem at my previous employer when moving images from one cluster to another and having the names change. This experience is unlikely to be relevant now. :classic_smiley:

9

This change has now been accepted by FESCo for Fedora Linux 41. This change can be tracked through tracker bug #2274818. A full set of the currently accepted changes can be found on the change set page.

1 Like
10

@mattdm @sgallagh Thanks for being patient! I need to log into Discourse more often. :man_facepalming:

In the 2016/2017 timeframe, the network device naming changed to better reflect how certain network devices were connected to the system. For physical nodes, it helped you know which device was onboard and which was on a particular PCI bus.

For cloud, the general consensus at the time was to keep everything the same as before and disabling consistent device naming was common. However, it still exists in place six years later. :wink:

It gets challenging in OpenStack environments where a device might be special, such as an SR-IOV device, and it can be difficult to identify if it uses eth0, eth1, eth2, etc. By using consistent device naming, it shows up consistently inside the guest with a predictable name. In some public clouds, some network devices are special, too. They might be using a network adapter that is a different type than the primary interface.

The worst possible scenario is when a network device that you expected on eth0 suddenly moves to eth1 later due to a hypervisor change of some sort. :scream:

Workstation, Server, and CoreOS moved away from net.ifnames=0 years ago as well.

1 Like
11

This change has been accepted by FESCo for Fedora Linux 41. A full list of approved changes to date can be found on the Change Set Page.

To find out more about how our changes policy works, please visit our docs site.

1 Like
12

In my experience, this way of naming interfaces can be consistent, but not necessarily predictable, especially when only one interface is involved.

When deploying the same disk image to different VPS providers, I got different interface names, so I used the following workaround to avoid messing with boot parameters:

sudo tee /etc/systemd/network/00-ether.link << EOF > /dev/null
[Match]
Type=ether
[Link]
Name=eth0
EOF