1. Proposed title of this feature request
Change interface name with respect to the last interface name
2. Who is the customer behind the request?
Union Switch & Signal Inc.
Account: UNION SWITCH AND SIGNAL 531660
TAM customer: no
CSM customer: no
3. What is the nature and description of the request?
4. Why does the customer need this? (List the business requirements here)
>> Customer : We need to automate the reconfiguration of interface names from the current persistent names to a static/standard names our software expects. With RHEL 7.5 ifname= (assuming it works) helps us with this however doing it by MAC address would require an extra amount of effort that I don't believe we want to handle.
For almost all projects we distribute identically configured hardware so all machines of a given class should have the same network interface names. We can exploit this fact and use the same setting to reconfigure these machines with the proposed change. If this was done by MAC address we would need to know all MAC addresses vs the interface name. This would also minimize the amount of configuration to be generated and tracked.
It's also possible this could be accomplished by other means. If Red Hat doesn't want to support dracut ifname= but would support the network interface name changing via anaconda kickstart 'network' line wou
ld work as well:
network --device p4p1 --ip 10.0.0.100 .... --name myint ...
5. How would the customer like to achieve this? (List the functional requirements here)
>> either by the following method in the dracut commandline
or the following method in kickstart
# network --device p4p1 --ip 10.0.0.100 .... --name myint ...
6. For each functional requirement listed, specify how Red Hat and the customer can test to confirm the requirement is successfully implemented.
>> Customer should be able to cheange the interface name with respect to the interface name of the
7. Is there already an existing RFE upstream or in Red Hat Bugzilla?
8. Does the customer have any specific timeline dependencies and which release would they like to target (i.e. RHEL5, RHEL6)?
>> RHEL 7
9. Is the sales team involved in this request and do they have any additional input?
10. List any affected packages or components.
>> dracut, kickstart
11. Would the customer be able to assist in testing this functionality if implemented?
I don't like the kernel option. To be general this would not have to be implemented only in dracut but also in the regular system (the network card can appear after boot). I think that kickstart option, that writes a custom udev rules would be better.
But I am a bit sceptical about the general usefulness of such option. I think the best way would be for them to craft their own udev rule, something like:
The original reporter here.
I would agree the kernel option might be the best idea.
Having an option for anaconda's network line would be better. However, anaconda shouldn't create udev rules but do whatever network manager would do: set 802-3-ethernet.mac-address and connection.interface-name. Allowing this to be configurable via nmcli/nmtui post install.
From the installer POV, the request implemented as a general supported feature should be implemented early and on lower level (initramfs). Implementing this feature in Anaconda on the level of NM connections would be too fragile and most probably produce a lot of inconsistencies to take care of when Anaconda synchronizes network configuration between installer initramfs / installer environment / target system initramfs / target system.
I think that, beside the custom udev rule, modifying the connections / ifcfg files in the %post section of kickstart could be a way in cases simple enough with regard to network configuration involved (eg no SAN, no manual UI configuration, ....), but as I said I am afraid we are not able to support general network command --name option as suggested.
Thanks for that input Radek.
This RFE has been reviewed by the Installer team and there are currently no plans to provide this functionality so I am going to close this BZ.
Derek, thanks for proposing this RFE. Lukas and Radek, both subject matter experts, appear to be in agreement that a udev rule is the way to go.