Linked by AdamW on Thu 27th Jan 2011 22:10 UTC
Fedora Core Fedora is holding a Test Day tomorrow (2011-01-27) to test a new network device naming scheme, as implemented by the biosdevname utility provided by Dell. biosdevname aims to give network interfaces names that are both consistent and appropriate to their physical attributes (onboard device number, or PCI slot), an approach that has been kicked around upstream for a while. This new system will likely come to most distros in future. The Fedora test day will concentrate on making sure it behaves as intended on both new installations and upgrades.
Thread beginning with comment 459995
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: And...
by gilboa on Fri 28th Jan 2011 07:18 UTC in reply to "And..."
gilboa
Member since:
2005-07-06

Even tried to explain to a sysadmin how one should look at lspci in-order to locate which devices are PCI and which are on-board so he/she will be able to understand which lines in each and every /etc/sysconfig/if-cfgX file and each line in /etc/udev/rules.d/70-persistent-net.rules should be changed just so two servers, each with multiple 1GbE and 10GbE cards, but with different firmware version will have the same device mapping? No?

... I'd give it some thought -before- calling this change a change for the sake of change, OK?

Plus, in the age of virtualization and high-performance networks assuming that a machine only has ethX devices (as opposed to ethX, brX, virtX, tapX, etc) is plain wrong.

Oh, and --please-- don't get me started about the mess that is called "Network device naming convention" under Windows.
I literally wrote a software that uses winpcap and reads various registry keys just to give the admins something that makes it remotely possible to understand which UUID belongs to which device. At least in that respect Windows is a bloody mess.

- Gilboa

Edited 2011-01-28 07:34 UTC

Reply Parent Score: 3

RE[2]: And...
by B. Janssen on Fri 28th Jan 2011 10:33 in reply to "RE: And..."
B. Janssen Member since:
2006-10-11

Even tried to explain to a sysadmin how one should look at lspci in-order to locate which devices are PCI and which are on-board so he/she will be able to understand which lines in each and every /etc/sysconfig/if-cfgX file and each line in /etc/udev/rules.d/70-persistent-net.rules should be changed just so two servers, each with multiple 1GbE and 10GbE cards, but with different firmware version will have the same device mapping? No?


Well, yes. That you are mucking around in individual interface configs shows me that you missed the point of persistent-net.rules. Then again, I don't find reading lspci output that hard ;)

Plus, in the age of virtualization and high-performance networks assuming that a machine only has ethX devices (as opposed to ethX, brX, virtX, tapX, etc) is plain wrong.


And the point would be? The suggested change is only concerning hardware NICs, not bridges, tunnels or virtual devices. Dell's little tool is not touching those.

I respect your anguish, GNU/Linux can be frustrating -- it certainly frustrates me from time to time -- but you seem to be confusing some things here.

Reply Parent Score: 2

RE[3]: And...
by gilboa on Mon 31st Jan 2011 20:43 in reply to "RE[2]: And..."
gilboa Member since:
2005-07-06

Well, yes. That you are mucking around in individual interface configs shows me that you missed the point of persistent-net.rules.


What makes you say that?
(See the comments below)

Then again, I don't find reading lspci output that hard ;)


Neither do I.
... But try explaining to a Windows admin how to sync persistent-net, if-cfg and lspci and you'll understand why this feature is -long- overdue.

And the point would be? The suggested change is only concerning hardware NICs, not bridges, tunnels or virtual devices. Dell's little tool is not touching those.


You have completely misunderstood my point.
My point was:
1. Giving network device according to their location (on-board, PCI-slot, etc) is a must when dealing with machines with large number of NICs.
2. Claiming that using non-ethX names will break modern network applications is absurd, given the large number of non-standard names being used today (brX, virtX, tapX, etc)

I respect your anguish, GNU/Linux can be frustrating -- it certainly frustrates me from time to time -- but you seem to be confusing some things here.


I believe you have completely mis-read my OP.

- Gilboa

Edited 2011-01-31 20:44 UTC

Reply Parent Score: 2