SUSE 10 and changing MAC addresses

[neergaard]

I was wondering if anyone has "solved" this problem: we have a SUSE 10.2 OS in a VMware image. When we copy it, the MAC address defined in the OS becomes a problem (since VMware changes the MAC address in the .vmx file). The easy way to solve this is to remove the existing NIC and recreate it, but that is a problem in our environment.

Does anyone have an automated way to deal with this?

Thanks,

Pete (neergaard@yahoo.com)

[oreeh]

Why don't you simply configure a static MAC address?

[neergaard]

These images will be used in a classroom environment, so there will be numerous of them sitting on the same LAN

Pete

[oreeh]

IIRC you can remove the MAC address from the /etc/sysconfig scripts without affecting their functionality.

[neergaard]

I should add that VMware deals with this better for Windows. When you copy the VM, upon starting the new copy VMware asks if you copied the image. If yes, then VMware generates a new MAC address. Somehow (don't know how), Windows sees this new NIC address and deals with it. When Windows boots up, everything is hapy as can be and the network interfaces all work. In SUSE (and I've seen this in the past with other versions of Linux) the new Mac address which is generated upon a copy is now inconsistent with what is stored in the local Linux configuration files... DOH!

[neergaard]

Oh... now that could be VERY useful.

In RH there was a radio button that allowed you to choose whether or not you tied the NIC to the MAC. If SUSE allowed something similar, that would be great. If I am understanding you correctly, you are suggesting that removing the MA address from the sysconfig file(s) that would accomplish the same thing...???

[RDPetruska]

Yep, Windows works better with this. Recent Linux versions started storing all network adapter configurations in a file with the MAC address of the adapter in the name of the file. So if the MAC address changes, the OS doesn't even realize it still HAS a network card!

[oreeh]

I'm not 100% sure (it has been a while since I had to deal with SuSE), so give it a try.

If it fails, you can always rewrite the init scripts.

[fejf]

Hi,

just remove the persistent MAC binding in your source-vm before cloning it:

rm /etc/udev/rules.d/30-net_persistent_names.rules

--

There are 10 types of people. Those who understand binary and the rest. And those who understand gray-code.

[neergaard]

> Hi,

> just remove the persistent MAC binding in your source-vm before cloning it:

>

> rm /etc/udev/rules.d/30-net_persistent_names.rules

Darn... didn't seem to work

[fejf]

Check if your network configuration files are configured correctly:

ls -la /etc/sysconfig/network/

There should be one ifcfg-ethX file for each (virtual) network card. So if you use one network card there should be a "ifcfg-eth0" file. If you used a different configuration style then rename the existing ifcfg file to ifcfg-eth0.

--

There are 10 types of people. Those who understand binary and the rest. And those who understand gray-code.

[neergaard]

OK... looks like we found a solution to the problem. Here it is:

1 - Rename /etc/sysconfig/network/ifcfg-eth-id-<MAC-ADDRESS> to ifcfg-eth0

...that seems to stay put and the system is happy with it.

2 - Remove the rule for eth0 in /etc/ udev/rules.d/30-net_persistent_names.rules

...the problem is that if you DON'T do this, when you copy the VM and the machine boots up, a new rule for eth1 gets created and the system ignores eth0 remember - the rule includes the original MAC address, so the new MAC address won't map to that rule...ergo new rule foreth1) . So then the system only defines eth1 which doesn't exist in /etc/sysconfig/network, so nothing works. If the rule for eth0 doesn't exist in the rule file, it recreates a rule for eth0 AND the configuration for eth0 exist (from step 1 above) and the world is happy.

The problem with this approach is that if the VM gets copied again, the new copier needs to remember to do this. Unlikely...

One of my buddies seems to have a SUSE VM that appears to NOT create new rules when the system is copied... almost like it isn't binding the MAC address to the NIC anymore for configuration information. Hmmm... just like RH is capable of doing. But he doesn't know how that happened. If I was able to figure that out, that would really help. That would mean that regardless of how many times the VM is copied, the NIC still works.

The alternative (which I want to avoid) is having a script run everytime the system boots causing a reconfiguration to occur... not a great idea.

Any advice welcome... thanks!

Pete

[fejf]

Removing persistent names:

Change network configuration to not use udev

1. Open /etc/sysconfig/network/config for editing

2. Find the line reading:

FORCE_PERSISTENT_NAMES="yes"

3. Change it to:

FORCE_PERSISTENT_NAMES="no"

4. Save

5. Reboot

Perhaps also read /usr/share/doc/packages/sysconfig/README.Persistent_Interface_Names

--

There are 10 types of people. Those who understand binary and the rest. And those who understand gray-code.

[neergaard]

That did it...... THANKS!!!

So, in summary, here is what I did:

1. rename the ifcfg-eth-id-<MAC-ADDRESS> to ifcfg-eth0 (in /etc/sysconfig/network)

2. remove the rules file (/etc/udev/rules.d/30-<rest of name here>

3. edit /etc/sysconfig/network/config and change FORCE_PERSISTENT_NAMES to "no".

Problem seems to be completely solved. I am able to make copies of copies of the VM image and the network continues to work (despite ever changing MAC address)

Pete