Weekly Edition
Return to the Distributions page
| |||||||||||||
Domsch: Consistent Network Device Naming coming to Fedora 15
Matt Domsch has been working on
Consistent
Network Device Naming for Fedora 15 (and beyond). "Systems
running Linux have long had ethernet network devices named ethX. Your
desktop likely has one ethernet port, named eth0. This works fine if you
have only one network port, but what if, like on Dell PowerEdge servers,
you have four ethernet ports? They are named eth0, eth1, eth2, eth3,
corresponding to the labels on the back of the chassis, 1, 2, 3, 4,
respectively. Sometimes. Aside from the obvious confusion of names
starting at 0 verses starting at 1, other race conditions can happen such
that each port may not get the same name on every boot, and they may get
named in an arbitrary order. If you add in a network card to a PCI slot,
it gets even worse, as the ports on the motherboard and the ports on the
add-in card may have their names intermixed."
(Log in to post comments)
Domsch: Consistent Network Device Naming coming to Fedora 15 Posted Jan 26, 2011 20:00 UTC (Wed) by sturmflut (guest, #38256) [Link]
I don't get it, how is this superior to the persistent net udev rules in Ubuntu/Debian? I'd rather have my device names bound to MAC addresses than bus IDs.
Domsch: Consistent Network Device Naming coming to Fedora 15 Posted Jan 26, 2011 20:07 UTC (Wed) by Pc5Y9sbv (guest, #41328) [Link]
This is one of those areas where the goals are a lot different if you're working on one complicated server versus rolling out racks of identical nodes.
Udev doesn't help if you you're trying to classify and use specific ethernet ports during anaconda kickstarts on brand-new hardware, for example. You may need to know which ethernet port(s) are on a management LAN, the production LAN, and the iSCSI SAN just to get the headless nodes to boot far enough to be provisioned and managed by someone.
Domsch: Consistent Network Device Naming coming to Fedora 15 Posted Jan 26, 2011 20:20 UTC (Wed) by foom (subscriber, #14868) [Link]
> I'd rather have my device names bound to MAC addresses than bus IDs
I sure don't -- I hate that method of device naming. I've had numerous situations where *everything breaks* when I replace a motherboard or a PCI ethernet card with the exact same model, because of Debian's MAC addr ethernet-port naming. And even in a simple autoconfig situations where the port name doesn't matter a whit, after I've gone through a few pieces of hardware, my ethernet port is now named "eth5" instead of "eth0", which is, though not broken, confusing.
Domsch: Consistent Network Device Naming coming to Fedora 15 Posted Jan 26, 2011 21:37 UTC (Wed) by ballombe (subscriber, #9523) [Link]
It is rather trivial to change the MAC adress in 70-persistent-net-rules.net so that your new interface get the number you want.
On the other hand, hard-coding the bus ID in the interface name require you to update all references to the interface name if the bus ID ever change.
Domsch: Consistent Network Device Naming coming to Fedora 15 Posted Jan 26, 2011 21:55 UTC (Wed) by tetromino (subscriber, #33846) [Link]
Sure, that works if you are talking about one machine. Now imagine that you have 100 identical servers, each with 4 network ports. Think of the administrative overhead (every single one of those 100 machines will require a different 70-persistent-net-rules.net) and the chance of making silly mistakes.
With Fedora's approach, you will only need to write one config per hardware platform, which is vastly more manageable for large organizations.
Domsch: Consistent Network Device Naming coming to Fedora 15 Posted Jan 26, 2011 23:28 UTC (Wed) by rahvin (subscriber, #16953) [Link]
Isn't this a prime example of it's hard to be everything for everybody? This is a single use case dictating a naming style that's different than the entire history of Linux and every other deployed distribution. I won't argue that it probably improves things for this single use case of a rack of systems with all the same hardware, but what's the expense to everyone else? Are we making management for everyone else more complicated and confusing to help a single use case? (might be a LOT of people/servers configured like this)
It's always bothered me that from my point of view the direction and development of Linux is driven by the server use case. Understandably that's where the money is that's paying to develop Linux but I think in the long run this single minded focus on servers at the expense of everything else damages the ecosystem.
Domsch: Consistent Network Device Naming coming to Fedora 15 Posted Jan 26, 2011 23:59 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]
If you are using the udev rules files and want to stick to it, you can even in Fedora. This only affects some server class hardware and that too it is completely optional. Also, Fedora is adopting it first but there is consensus between distributions and other distributions would be following on this in their upcoming releases.
Painting the bike shed Posted Jan 27, 2011 0:58 UTC (Thu) by cesarb (subscriber, #6266) [Link]
Sorry for picking your comment to reply to, but the level of drama for such a minor change is getting ridiculous.
Most people will not even notice, beyond the change of a label on NetworkManager's notification area menu. For most of those who notice, it will be nothing more than a change in a name they have to type. And in a few years, everyone will have gotten used to the new scheme, ethn being used only for old machines and wired USB connections. It is not like this is the first time there is a change to something everybody was used to on a Linux system.
On the other hand, for those who are the target group for this feature, it is a big change, for the better. These are the ones with things like 4 onboard Ethernet ports, which have to be correctly connected to completely separated networks (one management network, one storage network, one internal network, one external network...). Having the number in the interface name match the number printed on the outside of the chassis can make things a lot easier, even when configuring a single server (ok, I have eth0... which of the 4 physical ports it is, without having to test each one? And months later, when troubleshooting this server, can I at a glance tell which network eth3 is supposed to be connected to?).
Painting the bike shed Posted Jan 27, 2011 1:23 UTC (Thu) by tzafrir (subscriber, #11501) [Link]
Actually, an interface name with '#' in it? That's a nice stressing for various scripts around. Not everybody uses NetworkManager.
And consider the nice things that happen when you copy over your config to a new system that has the network adapter plugged elsewhere.
So yes, this does break some existing use cases. It better be worth it.
Painting the bike shed Posted Jan 27, 2011 7:21 UTC (Thu) by joib (guest, #8541) [Link] And consider the nice things that happen when you copy over your config to a new system that has the network adapter plugged elsewhere.How is that any worse than the current default which depends on MAC addressed stored on the disk? The new system won't have the same MAC addresses, and hence you get some random ethX numbers which don't reflect the config.
Domsch: Consistent Network Device Naming coming to Fedora 15 Posted Jan 28, 2011 22:30 UTC (Fri) by Tet (subscriber, #5433) [Link] It's always bothered me that from my point of view the direction and development of Linux is driven by the server use case.You're kidding, right? For me, by far the biggest problem with modern Linux is that the direction is nearly all driven by the desktop use case.
Domsch: Consistent Network Device Naming coming to Fedora 15 Posted Jan 27, 2011 11:22 UTC (Thu) by djzort (guest, #57189) [Link]
"Sure, that works if you are talking about one machine. Now imagine that you have 100 identical servers, each with 4 network ports. Think of the administrative overhead (every single one of those 100 machines will require a different 70-persistent-net-rules.net) and the chance of making silly mistakes.
With Fedora's approach, you will only need to write one config per hardware platform, which is vastly more manageable for large organizations."
Youve heard of scripts right? Tools like puppet or cfengine? Why are you managing 100 hand and custom built servers?
Domsch: Consistent Network Device Naming coming to Fedora 15 Posted Jan 27, 2011 17:39 UTC (Thu) by jeremiah (subscriber, #1221) [Link]
My understanding of this issue, is that exists BEFORE you have the chance to get puppet or cfengine up and running. If you're doing a new image of 100 machines, your image doesn't necessarily have access to the cfengine or puppet server. Esp if the ethX might have different names. After things are up and running and you know which net dev to connect through then you can apply cfengine or whatnot to the problem, and get the 'details' of the system setup. In a lot of ways this problem probably has more to do with initrd, BusyBox, and nash more than anything else. As someone who has to do this, building complex initrd scripts is a pain in the butt, esp when it's figuring out which fracking net dev is the right one to connect through. It's not the script that's hard, it's the image->cpio->take a guess at fix->cpio->image->boot->rinse repeat that's a pain. And the less guess work taken out of that the better.
</rant></ramble>
Domsch: Consistent Network Device Naming coming to Fedora 15 Posted Jan 26, 2011 23:20 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
I agree, that's why I have this disabled on all my debian systems.
just using the ports in detection order has proven to be _ar_ more reliable over time. the only thing I have to do is when I deploy a new kernel, I have to test it on a lab box first to make sure it didn't reorder anything (and guess what, I have to do that anyway to make sure that there aren't other problems with the kernel). I've been through a few cases where the order has changed, and it hasn't been nearly the problem that I've had with the 'tie to a MAC address' approach.
Domsch: Consistent Network Device Naming coming to Fedora 15 Posted Jan 28, 2011 12:37 UTC (Fri) by nix (subscriber, #2304) [Link]
What problem has tying to a MAC address given you? It should only cause problems if you change MACs all the time, and who does that?
Domsch: Consistent Network Device Naming coming to Fedora 15 Posted Jan 30, 2011 15:47 UTC (Sun) by rwmj (subscriber, #5474) [Link]
Welcome to the world of virtualization :-)
70-persistent-net.rules is a constant source of trouble when V2V-ing, migrating and cloning virtual machines.
In any case, the change mentioned in this article has nothing to do with udev's persistent naming, and all to do with how the network interfaces are named when you first install an OS. It's a reasonably sensible change, although given that this driven from the BIOS, there is plenty of room for BIOS vendors to fsck things up as they normally do.
Rich.
Domsch: Consistent Network Device Naming coming to Fedora 15 Posted Jan 27, 2011 12:15 UTC (Thu) by nim-nim (subscriber, #34454) [Link]
Big Enterprise customers (the ones Dell, HP and Red Hat sell to) have complex organisations where the team that racks a server in a datacenter is usually not the one that installs the system on it. That creates all kinds of problems on modern servers with multiple nic ports if the team that racks the server and the team that installs software on it have no common reference on what a particular nic port is (The racking team only knows the physical port labels it sees on the server, and the software team only knows the system port labels reported by the OS as displayed on its remote console. What Dell did is try to have both match. It will save lots of awkward phone call to its customers "if I plug it there, what interface do you see in the system, is it the right one this time" "Oops, the non-firewalled nic was plugged on the insecure public switch, etc"
Shell metacharacters Posted Jan 26, 2011 20:36 UTC (Wed) by cesarb (subscriber, #6266) [Link]
One thing I do not like in this... Why use a shell metacharacter? Isn't it asking for trouble?
Shell metacharacters Posted Jan 26, 2011 20:51 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]
Matt Domsch from Dell who is leading the development of this feature, replied to the same question earlier at
http://www.networkworld.com/community/fedora-15-changes-n...
Shell metacharacters Posted Jan 27, 2011 4:38 UTC (Thu) by HelloWorld (guest, #56129) [Link]
It is, and that's a Good Thing. Bourne-style shell scripting needs to die, and the sooner people realize that, the better.
Shell metacharacters Posted Jan 27, 2011 5:33 UTC (Thu) by jmm82 (guest, #59425) [Link]
Bourne-style shell scripting may be one of the most portable languages across all unix systems. We should probably rewrite auto-tools and convert every build system in the world to a new language?
Shell metacharacters Posted Jan 27, 2011 13:45 UTC (Thu) by HelloWorld (guest, #56129) [Link] That probably depends on your definition of portability. While it is theoretically possible to write bourne shell scripts that work on many platforms, almost nobody does because it's just too hard due to all kinds of differences both in the shell implementations and the tools that are available. Larry Wall was right when he said So, if you want to write a portable script, use perl. If your unix system doesn't have perl, it's dead anyway. And while perl isn't the be-all and end-all of scripting languages, it is a huge improvement over bourne style shells.
Shell metacharacters Posted Jan 27, 2011 16:19 UTC (Thu) by jmm82 (guest, #59425) [Link]
Hence auto-tools, what do you think "./configure" is doing?
Perl is not as easy to pipe multiple commands. I wish it was, but it just isn't. Also, in the embedded space microperl might reach the system, but not perl. Also, Perl is not any better to maintain than sh, maybe Python. With BusyBox you can run a lot of scripts with a few changes.
Funny you quote Larry Wall and say Bourne should be replaced by Perl.
Shell metacharacters Posted Jan 27, 2011 23:03 UTC (Thu) by cmccabe (guest, #60281) [Link]
Perl is not a shell. Therefore Perl can never replace the bourne shell.
Bourne shell scripts are still the right choice for SHORT (one or two page length) glue scripts. Once you start needing more, something like Ruby or Python is probably the right choice. Perl was really innovative in its day, but starting new projects in Perl is a terrible idea.
Shell metacharacters Posted Feb 23, 2011 18:53 UTC (Wed) by jrockway (subscriber, #71508) [Link]
What's wrong with Perl for new projects? New modern object systems like Moose? 20,000 free distributions on CPAN?
Honestly, people have written bad Perl in the past, but now they are writing bad Python and Ruby too :)
Shell metacharacters Posted Feb 23, 2011 22:34 UTC (Wed) by nix (subscriber, #2304) [Link]
Honestly, it's much easier to write bad Perl than bad Python. I'm a structure fanatic: my C, Python and Lua is structured as all hell. But I can't make my Perl look neat or structured no matter how hard I try: it disintegrates into a mess regardless.
And I am not the only person this is true of. Perl is a very messy language.
Shell metacharacters Posted Jan 27, 2011 10:25 UTC (Thu) by mpr22 (subscriber, #60784) [Link] Feel free to propose a ubiquitous, reliable alternative that makes every useful thing that is simple in Bourne-style shells no more complex than it is in Bourne-style shells.
Shell metacharacters Posted Jan 27, 2011 11:23 UTC (Thu) by djzort (guest, #57189) [Link]
"It is, and that's a Good Thing. Bourne-style shell scripting needs to die, and the sooner people realize that, the better."
How about something that looks like a Makefile? How about hmmm...Python?
Shell metacharacters Posted Jan 27, 2011 23:06 UTC (Thu) by cmccabe (guest, #60281) [Link]
> One thing I do not like in this... Why use a shell metacharacter? Isn't
> it asking for trouble?
Matt Domsch wrote:
> Yes. We did uncover one or two trivial-to-fix bugs in the Fedora
Shell metacharacters Posted Jan 31, 2011 5:39 UTC (Mon) by mab (subscriber, #314) [Link]
Why is there a need for a separator at all?
Shell metacharacters Posted Jan 28, 2011 19:48 UTC (Fri) by smurf (subscriber, #17840) [Link]
No script I know of is actually re-interpreting command lines.
Hashes in variable values don't even need quoting.
Shell metacharacters Posted Jan 31, 2011 21:21 UTC (Mon) by lakeland (subscriber, #1157) [Link]
Personally I like that. I use spaces in my file names - can you believe how many shell scripts break because they don't escape file and folder names? You start having default system installs with spaces and hashes in them and maybe shell script writers will include them in their testing.
Domsch: Consistent Network Device Naming coming to Fedora 15 Posted Jan 26, 2011 21:11 UTC (Wed) by tzafrir (subscriber, #11501) [Link]
How does it interact with USB-connected adapters?
You can easily get a bus ID. But if you happen to re-plug the device on a different slot (or through a hub), the bus ID changes.
Domsch: Consistent Network Device Naming coming to Fedora 15 Posted Jan 26, 2011 21:34 UTC (Wed) by cesarb (subscriber, #6266) [Link]
My turn to say "he already answered that". It is the third comment at http://domsch.com/blog/?p=455, as an answer to the first comment. Basically, no change.
Domsch: Consistent Network Device Naming coming to Fedora 15 Posted Jan 27, 2011 3:16 UTC (Thu) by clump (subscriber, #27801) [Link]
This will be a change from Linux's model of naming network devices as 'ethX', which has existed for many, many years. Such a change, according to Domsch's comments in the blog, will not provide soft links to the 'eth'-style of naming devices, which again, has existed for many, many years.
Rather than make such an invasive change that will break things relying on 'eth' names, why not soft link *from* eth devices to these new names? "Rejected upsteam"?
Zero backward compatibility is preferred? Users should now create a udev rule?
Domsch: Consistent Network Device Naming coming to Fedora 15 Posted Jan 27, 2011 5:14 UTC (Thu) by josh (subscriber, #17465) [Link]
Unlike just about everything else in UNIX, network interfaces don't work like files; no /dev/eth0 exists. And related to that, various assumptions get broken if more than one name exists for a given interface.
Domsch: Consistent Network Device Naming coming to Fedora 15 Posted Jan 27, 2011 5:50 UTC (Thu) by butlerm (subscriber, #13312) [Link]
I don't see the point in calling the onboard interfaces em0 .. em(N) when referring instead to onboard interfaces as eth0..ethN -- mapped the way as the "em" devices are going to be -- would presumably break compatibility with existing configurations to a much lesser degree.
In addition, I believe something like "eth_s3p1" would probably work better than "pci3#1" when referring to the first port on slot number three. If you have a fixed number of similar slots, the slot technology is probably irrelevant. And shouldn't a device name give some sort of indication of what type of device it is? "pci3#1" doesn't tell you without further context that someone is talking about a network interface.
If there were static device naming for serial ports wouldn't pci3#1 possibly be confused with the first serial port on slot 3 as well, for example?
Domsch: Consistent Network Device Naming coming to Fedora 15 Posted Jan 27, 2011 7:05 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
it's not always clear from the back of the system which pci slot is what number in terms of software (especially on servers where you may have several different variations of slot types)
the detection order of slot types varies between releases just as much as the detection order of network cards, in fact I've had more problems from the card slot order changing then I have from the card type order changing.
Domsch: Consistent Network Device Naming coming to Fedora 15 Posted Jan 27, 2011 16:37 UTC (Thu) by mebrown (subscriber, #7960) [Link]
sorry, incorrect.
There are several standard ways to get information about PCI slot numbering. The $PIR table being as old as the PCI standard, itself. The $PIR table will give you a mapping of how each PCI bus/dev is physically labelled. There are also newer standards using ACPI and SMBIOS tables for the same. (The newer standards also give a mechanism to label embedded devices with their physical label, which the older $PIR lacked.)
You are probably thinking of the older problem where NIC enumeration changed from depth-first search to breadth-first, changing the order in which ethX's were labelled.
This new mechanism completely solves the problem by relying on long-standing standards.
Domsch: Consistent Network Device Naming coming to Fedora 15 Posted Jan 27, 2011 20:19 UTC (Thu) by aleXXX (subscriber, #2742) [Link]
I fully agree, I thought the same when reading it.
Well, actually I thought that "emX" would be used only as a suffix to "eth".
Alex
Domsch: Consistent Network Device Naming coming to Fedora 15 Posted Jan 27, 2011 6:04 UTC (Thu) by jmm82 (guest, #59425) [Link]
Does this mean now Ethernet devices will have three possible interface names?
Why can't they write a udev rule to do naming based on bus location to the proper eth?
Also, I like how udev does /dev/disk and gives each device 4 names by-id, by-label, by-path, and by-uuid. These are all sym links to the Actual device like sda1. Yet, I am unaware of a way to give a Network device a second name similar to doing a sum link to a char or block device.
And no our scripts were not broken and even if we used variables for interface names this is still annoying.
Domsch: Consistent Network Device Naming coming to Fedora 15 Posted Jan 27, 2011 8:03 UTC (Thu) by joib (guest, #8541) [Link] Does this mean now Ethernet devices will have three possible interface names?Apparently, yes. However, this is not news; Not too long ago I used to run CentOS 5 on a laptop, where the Intel wireless card showed up as iwl0 rather than ethX. Not that it ever bothered me. Why can't they write a udev rule to do naming based on bus location to the proper eth? Apparently, the ethX namespace is verboten because it races with the kernel detected devices.
Domsch: Consistent Network Device Naming coming to Fedora 15 Posted Jan 27, 2011 16:11 UTC (Thu) by butlerm (subscriber, #13312) [Link] Apparently, the ethX namespace is verboten because it races with the kernel detected devices.So why not change the kernel so that it gives non-conflicting temporary names?
Domsch: Consistent Network Device Naming coming to Fedora 15 Posted Jan 28, 2011 12:51 UTC (Fri) by nix (subscriber, #2304) [Link]
Well, you can rename them to whatever you like, so anything other than the stuff in very early boot that renames them (pretty much, anything after udev runs) that relies on specific names is broken already.
(FWIW, I've been running Fedora systems with network interfaces udev-renamed to descriptive names for many years with no problems at all.)
Domsch: Consistent Network Device Naming coming to Fedora 15 Posted Jan 28, 2011 17:34 UTC (Fri) by jmm82 (guest, #59425) [Link]
@nix
Thank you for the clarification. That makes perfectly good sense. I guess I still feel that this could have been done more cleanly. Relaying on the network device name for bus location seems like a conflict of interests. I just hope people don't start depending on the names not changing.
Domsch: Consistent Network Device Naming coming to Fedora 15 Posted Jan 30, 2011 16:59 UTC (Sun) by nix (subscriber, #2304) [Link]
Agreed. It feels like a horrible and gratuitously nonportable layering violation to use PCI bus IDs for anything related to networking... I suppose in this case they *want* ambiguity, so that they'll get the same name on *every* machine with a card plugged into the same slot. Seems really risky to me, but, hell, I'm not the target market.
This is awesome Posted Jan 27, 2011 8:26 UTC (Thu) by joib (guest, #8541) [Link]
Congratulations to Mr. Domsch and his team for fixing this long-standing problem!
Domsch: Consistent Network Device Naming coming to Fedora 15 Posted Jan 27, 2011 9:29 UTC (Thu) by bpearlmutter (subscriber, #14693) [Link]
This problem is completely solved with storage devices and their partitions by having multiple names for each device or partition, so they can be referred to by hardware interface id, by uuid, etc.
$ ls -d /dev/disk/*
The only reason the same proper solution does not work for network devices is that their namespace lives outside the filesystem. So the *right* fix for the problem is to put their namespace back inside the filesystem, where it belongs. The hack under discussion above makes some things easier and others harder: it cannot fully solve the problem.
Domsch: Consistent Network Device Naming coming to Fedora 15 Posted Jan 27, 2011 16:58 UTC (Thu) by butlerm (subscriber, #13312) [Link]
/dev/disk/by-path is useful, but surely there is something deterministic that could be assigned that is simpler than "/dev/disk/pci-0000:00:1f.2-scsi-0:0:0:0" for a simple onboard SATA or SCSI disk.
Thirty years ago, on an Apple II one could issue commands like "CATALOG,S6,D2" and it would list the contents of the second drive connected to the sixth slot. Would it be so unreasonable to expect the OS to use information from the BIOS to determine that "this PCI / bus id connects to the first onboard disk interface, the second onboard disk interface", and so on, and allocate simple static names accordingly?
SMBIOS provides this information for onboard disk controllers and other devices in addition to Ethernet interfaces, I understand.
Domsch: Consistent Network Device Naming coming to Fedora 15 Posted Jan 28, 2011 22:28 UTC (Fri) by bpearlmutter (subscriber, #14693) [Link]
That isn't really a kernel issue, or anything deep. You can make more symbolic links, named as you please, with appropriate rules in the hal configuration files. In fact, names like you suggest would be a great addition, maybe /dev/disk/by-bus/pci/* and /dev/disk/by-bus/usb/* and such. Not sure if they'd see much use by scripts or automatic mechanisms, but they would certainly be useful to ls -lR and see what's what.
Domsch: Consistent Network Device Naming coming to Fedora 15 Posted Jan 27, 2011 11:48 UTC (Thu) by Wout (subscriber, #8750) [Link]
Currently many distributions create a MAC address to ethX mapping during installation. This ensures eth3 remains the same interface after every reboot.
Why not implement that same approach using PCI slots instead of MAC address?
So instead of associating a MAC address with an eth device, associate a PCI slot with each eth device.
That way we'd still have the ethX names we like, order is fixed (after first boot) and we can determine which eth interface corresponds with which physical interface. If the order is important to the user (eth1 must be pci1#2 on every node) then modify the configuration during install.
I really don't like the # in the new names by the way. It will cause a lot of problems.
Domsch: Consistent Network Device Naming coming to Fedora 15 Posted Jan 27, 2011 23:35 UTC (Thu) by Wol (guest, #4433) [Link]
"Order is fixed - after first boot".
Problem is, from reading other posts, the system won't boot until after the order is fixed ... the *install* CD needs to know which port is which so the box can find the screen/keyboard to let the administrator in.
Cheers,
Domsch: Consistent Network Device Naming coming to Fedora 15 Posted Jan 28, 2011 1:46 UTC (Fri) by hmh (subscriber, #3838) [Link]
Hmm? Anyone taking care of large datacenters has a deployment and configuration management tool. Such tools take care of updating udev rules (and anything else) at installation time easily. Also, you deploy a server type *once* by hand, write down the cabling sequence needed for use by the physical assets management team, upload the variable data management scripts to the deployment tool database, and everything else is done based on these templates. You *KNOW* what cable needs to go in what NIC to get a deterministic installer to select the right NIC.
When changing a NIC requires updating a config file for a given operating system, this IS known beforehand, and it IS written in the hardware config change checklist. It may be annoying, but it doesn't result on servers that don't boot.
So no, whatever this is about, it is certainly not about datacenters, and certainly not about first boot (when keying to MAC doesn't hurt).
Keying to PCI slots is actually less troublesome when a NIC needs to be replaced, but that does assume the user will not shuffle PCI boards around. Datacenters don't, but they don't actually need this whole stuff, anyway. Desktop users do shuffle boards around, and I am not sure what happens in a small shop with a few servers, and a single junior sysadmin.
It will also subject people to the usual negligence and incompetence found on desktop BIOS teams. You *WILL* get desktop boards with "To Be Filled By OEM" in the slot names, or with repeated slot names, or with control characters inside of ASCII in the slot names, etc. I sure hope that biosdevname tool is extremely paranoid and has a fallback to do something smart when it comes across such insanity.
Domsch: Consistent Network Device Naming coming to Fedora 15 Posted Jan 28, 2011 12:57 UTC (Fri) by nix (subscriber, #2304) [Link]
Desktop? I have servers with twelve NICs here, with 'To Be Filled By OEM' in every single one. I'd change them if I could, but, of course, I can't.
It is generally a mistake to trust system assemblers to get *anything* right that isn't needed to boot Windows with the absolute minimum set of drivers installed. Half the time they can't even get the right amount of RAM installed: what's the likelihood that they'll name network interfaces correctly in obscure BIOS tables?
(Some BIOSes aren't that bad, if the BIOS is something that comes *with* a specific peripheral and is made by the manufacturer of that peripheral. e.g. AtomBIOS on ATI cards. For anything else, the BIOS is liable to be rife with bugs, but even then less rife than the parts of BIOSes meant to be filled out by system assemblers.)
Domsch: Consistent Network Device Naming coming to Fedora 15 Posted Jan 27, 2011 20:28 UTC (Thu) by aliguori (subscriber, #30636) [Link]
When we introduced paravirtual block devices for KVM, we used the naming convention /dev/vdX because it seemed like a nice thing to do verses just exposing it like a SCSI device.
Over the years, I've been startled about the number of scripts (some in large projects) that assume all block devices are either /dev/hd* or /dev/sd* and subsequently broke.
I understand the motivation here, and agree that it's a useful thing to do, but lots of stuff will in break in subtle ways after this.
Domsch: Consistent Network Device Naming coming to Fedora 15 Posted Jan 28, 2011 1:03 UTC (Fri) by hmh (subscriber, #3838) [Link]
Hmm, it is a good idea, but the implementation suggested so far is not.
Naming the embedded port em<number> isn't so bad, other than the fact that it will break a lot of half-wit crap that needs the "eth" as the prefix to know something is an ethernet NIC. Stuff like iptraf, and a great many number of scripts. This is basically unavoidable, and acceptable collateral damage.
But a "pci" prefix for PCI/PCIe-attached NICs? You KNOW it is an Ethernet NIC, at least use a prefix that is not a BUS NAME...
iptables matching is done on prefix (e.g. em+, eth+). You WANT to be able to separate ethernet NICs from other devices by their prefix. Why not use a common prefix for all ethernet-like nics, like, say, "eth"? Sure, give us ethem<number> for the embedded ones, and ethpci<something> for the pci slot named ones. Or ethe<number> and ethp<number>, whatever.
The less said about the idea of using "#", the better. Just drop it, it is a Bad Idea. It adds no advantages and it is potentially hazardous. If you need something at all, use "_" or a letter.
There is no way we'd be able to take that crap naming convention in Debian, but we could certainly adopt the whole idea if the naming was more palatable. And THIS is something we'd all benefit if every distro decided to do in the same way.
Domsch: Consistent Network Device Naming coming to Fedora 15 Posted Jan 28, 2011 20:25 UTC (Fri) by mdomsch (subscriber, #5920) [Link]
Thanks everyone for your insightful comments. I appreciate the votes in favor, and for helpful suggestions when you're not quite convinced yet...
It's fairly likely that we'll change from using '#' to something else (perhaps 'p' for "port") to avoid the parsing problems which are sure to appear. That's still under investigation.
Mind you, there are only 15 characters of IFNAM size, and 5 of them are already "claimed" by vconfig when creating VLANs on an interface (suffix of .1234). That realistically leaves only 10 characters for all other purposes, including :alias usage (though that should be deprecated - patches welcome to remove that from Fedora initscripts). In general we'll use three ("em1") or six ("pci4#1"), or nine ("pci4#1_62") in the SR-IOV case, so we're right up on that limit. The initial "pci" bit is to identify PCI sockets as seen on the back of the chassis, apart from embedded NICs that aren't removable. I'm open to other suggestions for scheme, but a) it can't be longer than this; b) it can't start with eth(:digit:)+.
Domsch: Consistent Network Device Naming coming to Fedora 15 Posted Jan 29, 2011 7:16 UTC (Sat) by butlerm (subscriber, #13312) [Link] Mind you, there are only 15 characters of IFNAM sizeIsn't that like, so 1983? Surely 30 characters or more would be a much more reasonable limit for interface names, given all the things that can be tacked on these days.
Domsch: Consistent Network Device Naming coming to Fedora 15 Posted Jan 29, 2011 14:34 UTC (Sat) by mdomsch (subscriber, #5920) [Link]
Unfortunately, the kernel->userspace ABI for network ioctl() calls defines the interface name to be IFNAM size, or 15 characters usable. It would be impossible to change every userspace program ever produced and in use to allow for a longer device name.
Domsch: Consistent Network Device Naming coming to Fedora 15 Posted Jan 31, 2011 15:36 UTC (Mon) by cesarb (subscriber, #6266) [Link]
> I'm open to other suggestions for scheme
Since you asked for it...
es<slot>p<port>v<vf>
This gets rid of all non-alphanumeric characters, uses a generic "s" for "slot" instead of "pci" (which implies PCI, even if other technology is used in the future - or in the past as in ISA and MCA), and adds an "e" prefix (for Ethernet, becoming similar to your "em"). So you have:
em1
You could also omit the port number for single-port add-on cards, so for instance if the card on slot #4 only has one port, you could have "es4" and
I think this scheme is shorter, prettier, and easier to pronounce over the phone.
Domsch: Consistent Network Device Naming coming to Fedora 15 Posted Jan 31, 2011 16:50 UTC (Mon) by bronson (subscriber, #4806) [Link]
Love it. And if the catchall 's' is unweildy, you can have 'sp' for PCI, 'si' for ISA, etc.
As an ex-NOCmonkey, I really like the attention paid to phone readability. When the servers are on fire and the whole team is conferenced together, it's not fun to spend a minute trying to agree on what '#' and '_' are called.
Domsch: Consistent Network Device Naming coming to Fedora 15 Posted Jan 31, 2011 21:40 UTC (Mon) by cesarb (subscriber, #6266) [Link]
> And if the catchall 's' is unweildy, you can have 'sp' for PCI, 'si' for ISA, etc.
I believe that is not the idea. The idea is, as far as I understood, to match the *labels* on the outside of the server. So the slot marked as "1" on the outside of the server should have a "1" on its network interface name, indifferent as to whether it is a PCI slot, a PCI-X slot, a PCIE slot, an ExpressCard slot some crazy hardware designer decided to add to a server, or some even crazier stuff (SDIO perhaps?).
Putting it in another way, what is in the inside (the bus used) does not matter, it is what is on the outside (the onboard port numbered Y or the slot numbered Z) that matters.
Domsch: Consistent Network Device Naming coming to Fedora 15 Posted Jan 31, 2011 21:43 UTC (Mon) by cesarb (subscriber, #6266) [Link]
I just thought of yet another advantage of my scheme: with it, "iptables ... -i e+" matches everything Ethernet (ethX, emX, and esXpY...), in a single rule.
|
|||||||||||||