Re: overriding udev rules

[Lennart Poettering <lennart@poettering.net>]

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...

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...)

Lennart

-- 
Lennart Poettering - Red Hat, Inc.