[BlueOnyx:08455] Re: vmware ESXi 4.0 and 5107R

[Michael Stauber]

Hi Miguel,

> I configured the settings in the ESXi for the cloned VPS and changed
> the MAC, rebooted the VPS and now the system continues keeping
> the eth0 (with old MAC) and adds the eth1 (with new MAC).

Ah, I see.
 
> Maybe there is a cleaner way of doing this, but at least it is working.

Yeah, I just checked. The constructor 
/usr/sausalito/constructor/base/network/30_addNetwork.pl that I mentioned in 
my earlier message doesn't actually update the MAC address into the CODB 
database on MAC address changes. It just inserts that info once for any given 
NIC and then just updates IP and netmask as needed. After all: As far as the 
GUI is concerned the MAC is not really of any importance to us.

However, there is something else that played a role and that probably threw a 
wrench into the detection of your eth0:

EL6 (RHEL6, CentOS6, SL6) has a newer UDEV. It keeps track of the MAC address 
of ethernet devices in a file called /etc/udev/rules.d/70-persistent-net.rules

That's supposed to help you make sure that the same NICs are always used for 
the same bindings. Which is a bit nuts, as that functionality was already 
present with the HWADDR line in the network config scripts. 

Sadly the info in /etc/udev/rules.d/70-persistent-net.rules takes precedence 
over the HWADDR lines in your ifcfg-eth* files.

So I think your /etc/udev/rules.d/70-persistent-net.rules config file still 
had the old MAC for eth0 on record and wouldn't let you use eth0 with the new 
MAC that you set up for the network interface through ESXi.

To fix this you could edit /etc/udev/rules.d/70-persistent-net.rules and 
simply remove all the "SUBSYSTEM=" lines at the end. Then reboot and it should 
be fine. 

The more I think about /etc/udev/rules.d/70-persistent-net.rules, the more I 
find it likely that I will add a mechanism to BlueOnyx that will disable this 
botched feature that RedHat chose to implement. Because it really looks like 
it hurts more than it helps. 

-- 
With best regards

Michael Stauber