Re: overriding udev rules
On 08/22/2013 03:12 AM, Peter Samuelson wrote:
>
> [Thomas Goirand]
>> Oh ok. Not useful at all if you ask me. Why? Because sometimes, you
>> can't change the MAC address. For example, if you use the OpenStack
>> bare metal driver, then you continue to use virtual machine images,
>> though they will be used on a real hardware where you can't change
>> the MAC address.
>
> So you're saying, when your NIC is tied to actual physical hardware,
> udev behaves as though it is tied to actual physical hardware.
No. I'm saying that udev is making the wrong assumption that virtual
machines are only bound to a specific MAC address range, when this is
not at all the reality, for example when using read hardware for running
cloud applications.
> Seriously, the reason for udev to not make a VM NIC persistent is not
> because it is virtual, per se, but because certain virtualization
> platforms may randomly generate a MAC at boot time.
What is happening is udev is making assumption on what type of usage one
will do with a piece of hardware. There must be some clean ways to
disable such feature, which by the way, has always annoyed me (even when
not using cloud computing or even virtualization).
> I think the problem you're trying to solve is more related to imaging
> and cloning. The fact that you're doing imaging and cloning in the
> context of virtual machines instead of physical is a bit of a red
> herring.
You can't tell that my usage is wrong, and the software is right.
Software should be adapted to use cases, and not the opposite way.
Thomas
Reply to: