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