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

Reply via email to