Bug 229579 - kudzu deletes network configuration on identical hardware
kudzu deletes network configuration on identical hardware
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kudzu (Show other bugs)
4.4
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Bill Nottingham
David Lawrence
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-02-21 16:27 EST by Scott Leerssen
Modified: 2014-03-16 23:05 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-02-12 12:27:15 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Scott Leerssen 2007-02-21 16:27:45 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.9) Gecko/20061206 Firefox/1.5.0.9

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):
kudzu-1.1.95.15-1

How reproducible:
Always


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)


Actual Results:
/etc/sysconfig/network-scripts/ifcfg-eth0 goes away.

for additional fun, reboot so you can't access the box any more

Expected Results:
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.

Additional info:
Comment 1 Bill Nottingham 2007-02-21 16:44:16 EST
This is expected; the primary key for a network adapter is its mac address.
Comment 2 Scott Leerssen 2007-02-21 17:04:44 EST
This breaks virtualization.  Even VMware images moved from one system to another
will suffer this issue if kudzu happens to run.
Comment 3 Scott Leerssen 2007-02-21 17:09:26 EST
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.
Comment 4 Bill Nottingham 2007-02-21 17:14:27 EST
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.
Comment 5 Scott Leerssen 2007-02-22 09:08:19 EST
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
them alone.

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
feedback.
Comment 6 RHEL Product and Program Management 2007-05-09 03:19:53 EDT
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
release.
Comment 7 Bill Nottingham 2007-05-22 17:59:00 EDT
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.
Comment 9 Robert K. Moniot 2008-01-11 14:22:36 EST
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.
Comment 10 Greg Bock 2008-02-11 16:58:55 EST
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.
Comment 11 Bill Nottingham 2008-02-11 17:23:32 EST
#10 - No such change was made in RHEL 4.
Comment 12 Greg Bock 2008-02-11 18:18:29 EST
Sorry, I meant previous behavior in RHEL 4 versus current behavior in RHEL 5.
Comment 13 Bill Nottingham 2008-02-12 12:27:15 EST
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)

Note You need to log in before you can comment on or make changes to this bug.