|Summary:||kudzu deletes network configuration on identical hardware|
|Product:||Red Hat Enterprise Linux 4||Reporter:||Scott Leerssen <scott>|
|Component:||kudzu||Assignee:||Bill Nottingham <notting>|
|Status:||CLOSED WONTFIX||QA Contact:||David Lawrence <dkl>|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2008-02-12 17:27:15 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
Description Scott Leerssen 2007-02-21 21:27:45 UTC
From Bugzilla Helper: User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:188.8.131.52) Gecko/20061206 Firefox/184.108.40.206 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-220.127.116.11-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 21:44:16 UTC
This is expected; the primary key for a network adapter is its mac address.
Comment 2 Scott Leerssen 2007-02-21 22:04:44 UTC
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 22:09:26 UTC
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 22:14:27 UTC
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 14:08:19 UTC
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 07:19:53 UTC
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 21:59:00 UTC
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 19:22:36 UTC
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 21:58:55 UTC
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 22:23:32 UTC
#10 - No such change was made in RHEL 4.
Comment 12 Greg Bock 2008-02-11 23:18:29 UTC
Sorry, I meant previous behavior in RHEL 4 versus current behavior in RHEL 5.
Comment 13 Bill Nottingham 2008-02-12 17:27:15 UTC
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)