Re: overriding udev rules
On 09/10/2013 02:50 AM, Lennart Poettering wrote:
> On Mon, 26.08.13 01:22, Thomas Goirand (zigo@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.
Reply to: