Marc Haber wrote: >On Fri, 8 May 2015 07:59:31 +0200, Martin Pitt <mp...@debian.org> >wrote: >>Details about [ifnames] >>----------------------- >>This is a generic solution which extends the [biosdevname] idea and >>thus applies to all practical cases and all architectures. It doesn't >>need any persistant state (i. e. dynamic /etc/udev/rules.d/) and thus >>applies nicely to snappy/touch, and also avoids the race condition. >> >>The main downside is that by nature the device names are not familiar >>to current admins yet. For BIOS provided names you get e. g. ens0, for >>PCI slot names enp1s1 (ethernet) or wlp3s0 (wlan). But that's a >>necessary price to pay (biosdevname names look similar). >> >>As this hasn't been discussed yet, Debian and Ubuntu disable this by >>default. You can opt into this by booting with "net.ifnames=1" (which >>is a patch against upstream: there you disable it by booting with >>net.ifnames=0 or disabling 80-net-setup-link.rules). >> >>Proposal >>-------- >>I propose to retire [mac], i. e. drop >>/lib/udev/rules.d/75-persistent-net-generator.rules and enable >>[ifnames] by default. > >I have tried this just last week and have found it kind of >unsatisfactory that it doesn't work in virtualized environments. For >example, in a KVM VM with virtio ethernet, the network devices still >end up in the system as eth0, eth1, eth2.
As I understand it, that's intentional and expected, for two reasons. First, because on a virtual machine, the network interfaces are likely to be more stable, always showing up with the same numbers. And second, because there's little else to go on when naming them. - Josh Triplett -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150508072843.GA5466@x