Red Hat Bugzilla – Bug 229579
kudzu deletes network configuration on identical hardware
Last modified: 2014-03-16 23:05:41 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:220.127.116.11) Gecko/20061206 Firefox/18.104.22.168
Description of problem:
When moving an image from one server to another (e.g. reassignment of a fibre channel LUN), kudzu (run at startup with -q) deletes all of the ifcfg-eth* files from /etc/sysconfig/network-scripts, even though the NIC hardware types may be the same. It appears that the change in MAC address triggers this removal. This is rather annoying when using mostly similar hardware to support disaster recovery or automated load management. This seems to be new behavior; my recollection is that network configuration would remain even though the MAC address or NIC driver may change.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
A simple way to test w/o actually using a SAN:
1. change the network.hwaddr value of your eth0 entry in /etc/sysconfig/hwconf
2. run 'kudzu -q' (as root, of course)
/etc/sysconfig/network-scripts/ifcfg-eth0 goes away.
for additional fun, reboot so you can't access the box any more
The network configuration (ifcfg-eth0) should at least stick around so eth0 has a chance of coming up with an address. Ideally, if the HWADDR line is present in ifcfg-eth0, just change it. Incidentally, our config files do not contain that line... on purpose.
This is expected; the primary key for a network adapter is its mac address.
This breaks virtualization. Even VMware images moved from one system to another
will suffer this issue if kudzu happens to run.
I should also mention, that this is also an issue for diskless (NFS root)
support when moving an image around a cluster of mostly identical hardware.
The best solution in that case is to disable the kudzu service.
In RHEL 5, the ifcfg files are renamed instead of removed. That code change
could be backported.
kudzu is really handy for reconfiguring drivers when moving an image around to
different pieces of hardware. One neat trick is to move /etc/modprobe.conf and
/etc/sysconfig/hwconf out of the way and let kudzu find a new hardware
configuration when an image is booted. Most of the time, this works (for
diskless anyway, or clever use of initrd for controller types). The networking
going away can be resolved short term by wrapping the kudzu rc script with a
backup and restore of the ifcfg-eth* files, but I'd much rather kudzu just leave
Renaming may still end up the interfaces not being enabled at startup, though,
unless /etc/rc.d/init.d/network doesn't ignore them, or they are being edited to
match the curent configuration (THAT would be handy).
For what it's worth, kudzu currently leaves the route-ethX, ifcfg-vlan and
ifcfg-ethX:Y alias files alone, as well as iptables definitions. I think it
would be more consistent to just leave the ifcfg-ethX files alone, and if new
interfaces are found, either replace the HWADDR if there is a reasonable guess
which NICs are being replaced, or just add a disbled config file with the new
HWADDR. A -N option (to leave the /etc/sysconfig/network-scripts alone) might
be nice, too, in case there is a use case for actually removing/renaming the files.
kudzu is a great tool for hardware mobility and virtualization. Thanks for
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release. Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products. This request is not yet committed for inclusion in an Update
Renaming isn't going to edit the files - that's way out of the scope of what
kudzu's going to do, especially in the case of 3 entries removed, two added ;
attempting to guess what goes where isn't practical.
I think this behavior is also what is causing us a small inconvenience when
ghosting a disk image. On booting the newly ghosted machines, whose MAC address
obviously differs from that of the reference machine, which is in
/etc/sysconfig/hwconf and /etc/sysconfig/network-scripts/ifcfg-eth0, what it
does is to rename ifcfg-eth0 to ifcfg-eth0.bak and then try to create
ifcfg-eth1. The latter doesn't work, however, since there isn't any /dev/eth1
on these machines. Seems kudzu could be smarter about figuring out that the MAC
address has changed and simply update it in ifcfg-eth0.
From the above discussion it seems the workaround would be to delete hwconf and
remove the HWADDR line from ifcfg-eth0 on the reference machine before creating
the ghost image. I'll try this next time we do a ghosting.
The real behavior change went from asking for a configure/ignore/do nothing/ and
timing out with no input, to simply backing up the files and changing them. I
would like a revert to previous behavior or if possible a setting in
/etc/sysconfig/kudzu to disable network, and possibly other component group,
testing if desired. I believe the latter would benefit most of the use cases and
generally speed up boot times when hardware or VM changes are made.
#10 - No such change was made in RHEL 4.
Sorry, I meant previous behavior in RHEL 4 versus current behavior in RHEL 5.
For RHEL 4, the solution really is if you don't want to automatically change the
configuration on MAC address changes to either:
a) don't run kudzu
b) don't run it with -q (which is not the default)