Consistent Network Device Naming updates

Today I released biosdevname v0.3.7, after listening to feedback from all across the web, including NetworkWorld, LWN, and Slashdot.  No, I’m not killing the feature, as some might hope, but some changes are in order.

First, it’s amazing how many people hated the ‘#’ character in device names.  Yes, that was bound to cause some problems, but nothing that couldn’t be fixed given enough time.  But since it’s early in the game, changing that character from ‘#’ to ‘p’ accomplishes the same goal, with less chance of breakage, so that’s done.  pci<slot>p<port>_<vf> it is….

Second, the various virtual machine BIOSes each do something slightly different for the network devices they expose.  VMware exposes the first NIC (traditionally eth0) as in PCI slot 3.  KVM exposes the first NIC as in PCI slot 2, but has no information about the second NIC.  Xen doesn’t expose anything, so those all kept the ethX naming convention.

To address these discrepancies, and because there is no physical representation of a (virtual) NIC in a virtual machine, biosdevname no longer suggests a new name for NICs if running in a VM guest.  This means all VM guests keep ethX as their naming convention. Thanks to colleague Narendra K for this fix.

Third, for everyone who still thinks renaming devices is a really bad idea, you get an out.  A new kernel command line option, honored by udev, lets you disable biosdevname.  biosdevname=0 will prevent biosdevname from being invoked, effectively disabling this feature, leaving you with the ethX names.

All this, and the usual assorted bug fixes as biosdevname gets more widespread exposure and testing.

Love it?  Hate it?  Let me know.  You can find me (mdomsch) on IRC on FreeNode in #biosdevname, #udev, or #fedora-devel, as well as the usual mailing lists.

7 thoughts on “Consistent Network Device Naming updates

    • It turns out all we need for biosdevname purposes is one CPUID instruction call, ~5 lines of code, so not really any codebase to synchronize. We looked at using virt-what, but even that was overkill for our purposes.

  1. From a sysadmin standpoint, I *love* this idea and look forward to it being adopted everywhere. I know the standard desktop user and the new linux users are the ones who are strongly opposing this, but they don’t know it’s for their own good. I imagine the ones most worried about this are new linux users administering firewalls that will have their iptables rules ripped out from underneath them. They don’t understand that this brings a more-sane naming than the hap-hazard guessing they had before.
    Like I said, *love* it.

      • Cesar, we may wind up with something like this. My colleague Jordan Hargrave is taking over the project from me, and is investigating a few options here. One is:

        as there are some “embedded” devices which can really be field-replaceable, just in a dedicated NIC-specific slot (not a generic PCI slot). Given the realistic 10-character limit, having 2 characters up front won’t fit, and my ‘pci’ nomenclature won’t fit either.

        The only difference then is your proposal suggests using letter ‘v’ where I have an underscore.

  2. Looking really forward to this one. In fact, I’ll just try installing it on Ubuntu 10.04 and see how things work out. Well, not in a VM though 🙁

    It sure will break our own scripts, but as you pointed out earlier, they are already borken.

Comments are closed.