1 |
On Monday 30 September 2013 10:01:32 Alan McKinnon wrote: |
2 |
> On 30/09/2013 06:14, Walter Dnes wrote: |
3 |
> > If the udev people had made "net ifnames=0" the default, and allowed |
4 |
> > |
5 |
> > the small percentage of multi-nic machine admins to set "net.ifnames=1", |
6 |
> > this would not have been an issue. Some corner case exotic setups |
7 |
> > require complex solutions... no ifs/ands/ors/buts. All the complaining |
8 |
> > you hear is from the other 99% who's setup worked just fine with the |
9 |
> > simple solution, suddenly finding the complex solution rammed down their |
10 |
> > throats. |
11 |
> |
12 |
> No, that is just plain wrong. |
13 |
> |
14 |
> Having interfaces on a multi-nic host come up as ethX where X is a |
15 |
> mostly random number is just so broken it beggars belief. Trust me, it |
16 |
> is zero fun when it happens and what makes it even worse if you have no |
17 |
> warning at all beforehand. |
18 |
|
19 |
I trust you, but on my multi-nic systems, I found a better solution :) |
20 |
As I use Xen to virtualize my systems and as I don't want to have multiple |
21 |
network cables running side-by-side, I started using VLANs. |
22 |
|
23 |
I know have all the NICs names eth1,eth2,...ethn. |
24 |
I throw them all as a bonded network device: bond0 (the other ends go into a |
25 |
switch supporting bonding network ports) |
26 |
then on top of that, I have VLANs with distinctive names (lan, dmz, guest, |
27 |
vm,...) and link these as required to different Xen-domains. |
28 |
|
29 |
When the network names get renamed suddenly to the "non-predictive" scheme, my |
30 |
system refuses to boot. |
31 |
Before that, I would use mac-addresses to link ethx devices to names that make |
32 |
sense to me. (see above for the names) |
33 |
|
34 |
-- |
35 |
Joost |