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 -- 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/52188c53.9040...@debian.org
