On 09/10/2013 02:50 AM, Lennart Poettering wrote: > On Mon, 26.08.13 01:22, Thomas Goirand (z...@debian.org) wrote: > >> >> On 08/24/2013 03:53 PM, Ben Hutchings wrote: >>> There is a very clear standard that distinguishes globally and locally >>> administered addresses. >>> >>> While you would possibly to buy your own OUI and make global assignments >>> to your VMs, I seriously doubt you are doing that. Don't steal address >>> space. >>> >>> Ben. >> >> By reading the above, I don't think I made myself clear enough. >> >> In the case of a bare-metal driver for cloud computing IaaS, you would >> an have operating system image that could be booted once on one physical >> machine, then shutdown and later restarted on another hardware. In such >> use case, physical hardware is used to run the virtual machine images >> without virtualization. It is *not possible to choose the MAC*, as this >> is the one that is physically in the hardware, though udev should >> continue to behave "as if it was a virtual machine MAC address". >> >> Therefore, I think there should be an easy, documented way, of telling >> udev to behave one way or another. I'd say /etc/udev/udev.conf could be >> the correct place to configure this. If we want to keep the current >> behavior of double-guessing the use case of the network interface (which >> I recognize is the most useful case), then it could stay as default, as >> long as there is a reliable way to configure udev. > > systemd/udev upstream do not assign "persistent" fixed names anymore to > network interfaces, in order not to race against the kernel. Instead we > now assign predictable names insteads, which avoids the whole issue. > > See > http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ > > The resulting names are somtimes a bit ugly, but predictable and stable, > and do not change on every VM reboot...
They are predictable from within a booted linux install with a new kernel. They are stable as long as the kernel and the hardware do not change too much; e.g. enabling the "other" graphics card in a hybrid setup sometimes adds a PCIe bus, so all names shift around. There are still race conditions. > > It's now a Debianism to stick to the persistant names, all support for > it has been removed upstream. From upstream we hope DEbian eventually > drops support for the old persistant names too. > > As a side note, also note that the MAC address range definitions are all > blurred these days, MAC addresses are reused by manufacturers and most > parsable meaning of MAC addresses has been removed (simply because the > namespace is mostly depleted these days...) Reusing would be extremely bad - Medion once shipped a few charges of machines with the same MACs on all, so people that bought more than one had fascinating network failures. I hope no vendor is *THAT* insane and still allowed to assign MACs. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/522e6270.1010...@gentoo.org
