[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: overriding udev rules

On Mon, 2013-08-26 at 01:22 +0200, Thomas Goirand 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.

Sorry, I get it now.  That's not something I've ever heard of people
doing on a regular basis, but I can see you would want to override
udev's behaviour in this case.

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

The current behaviour is right for almost everyone, and it doesn't need
to be that easy to change it.

What you're asking for is, I think, doable with:

echo >/etc/udev/rules.d/70-kernel-net-device-name.rules \
'ACTION=="add", SUBSYSTEM=="net", NAME="%k"'

But you don't actually want that behaviour.  You cannot assume anything
about the order in which net devices are created and therefore you still
need rules for persistent names unless your machines have only one
Ethernet(-like) interface (the usual VM case).

You'll need to install rules that work out which interface should be
'eth0' (or, better, some meaningful name) based on the site conventions
for wiring up network ports.


Ben Hutchings
This sentence contradicts itself - no actually it doesn't.

Attachment: signature.asc
Description: This is a digitally signed message part

Reply to: