F18: unpredictable 'Predictable Network Interface Names'?

[Bill Davidsen]

Marko Vojinovic wrote:
> On Mon, 25 Feb 2013 21:15:40 -0500
> Tom Horsley <horsley1953 at gmail.com> wrote:
>> On Tue, 26 Feb 2013 03:10:59 +0100
>> Marko Vojinovic wrote:
>>
>>> The actual difference between the two methods is about system
>>> maintenance
>>
>> Yea, and when you update your system with a new and improved
>> biosdevname, you can find nothing working because the
>> "immutable" names have changed:
>>
>> http://home.comcast.net/~tomhorsley/game/biosdevname.html
>>
>> Loads of fun for everyone!
>
> Well, everything has bugs. And you saw how badly motherboard bioses can
> be written, it is not easy to write something like biosdevname and have
> it working perfectly for everyone in its very first version. Btw, I am
> not trying to play an advocate for biosdevname here, but rather just
> trying to understand why the OP needs MAC-based naming so badly.
>
The problem here is that the whole naming implementation is based on the 
assumption that people want to name slots. That might be true if you have a 
single server, but in a data center with hundreds of rack mounted servers, it's 
not. When a server goes bad it is replaced with the current model for that load, 
which generally changes every 12-24 months as new models come out. So a 
replacement with different biosnames is the norm, and putting labels on the back 
of the NIC next to the port is the norm. DASD is external, so that just plugs 
in, but anything based on slot names is going to be wrong.

In addition to assuming that slots will not change, the assumption is made that 
all NICs are the same, and that any NIC plugged into a slot will do. Alas, 
that's not the case in a large data center, a mix of single and dual NIC cards 
is common, and some fiber is possible, perhaps for NAS. biosname introduces the 
requirement that every NIC must go in the right slot, one more labeling thing to 
do and possibly go wrong.

A good implementation would allow naming by slot, or MAC, or just a default like 
calling the first one eth0 and the next eth1. It would be done in one and only 
one place and use a human readable text file for config. We don't seem to have 
that, and the default of an unpredictable name in all cases justs adds one more 
thing to be overcome.


-- 
Bill Davidsen <davidsen at tmr.com>
   "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot