New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RFC: biosdevnames auto detection #1400
Comments
@gdha, I think adding KERNEL_CMDLINE I usually don't like when an application force the user to modify the current system. Moreover, as I explain in #1020 there is several way to activate biosdevname. One is a script managed by systemd (which override KERNEL net.ifname parameter if I remember well). IMHO we should rethink the way we are assigning IP address in the recovery image (based on MAC).
This wrapper function will look for interface name with 00:01:02:03:04:05 MAC and then run the real If the MAC address cannot be found, then we should ask the user to choose the interface from a list. This can be also useful for new system like ubuntu, rhel7 ... which has drop undev/70-persistent-net rules. Today, when you migrate a "multi inet" rhel7 to a NEW system (means new MAC)`, inet migration is not detected and IP is "blindly" assign to the same inet name (eth0 for exemple.. You need to be sure to get the inet in the same order (easy for VM, less for Bare metal system with 1GB for admin, 10Gb or even 40Gb for production.... the order will be given by the kernel module load order.) My final thought in one sentence: It is time to rethink the network configuration / migration part. (Today mostly based on device name, based on udev persitent-net rules which are now dropped in distro like ubunu & redhat.) |
@schabrolles I fully understands the business concerns, however, we should not rush and change blindly our network scheme to a new model as we may potentially break more then we fix. I do agree with have to prepare ourselves for new challenges that come along with network layer. |
@gdha, don't worry, I don't want to change blindly everything in the network scheme but may be propose some evolution in order to use the latest distro. I don't understand your point regarding SAP HANA migration with 6 adapters:
extract from 55-migrate-network-devices.sh
But let this migration point aside for the moment. We still have an issue during recovery on the same system when a user disable Solutions / workaround:
I made a first prototype which work now on the following scenario (ubuntu 16.04):
example of new 60-network-devices.sh generated
ip_mac() function
full commit changes available here: schabrolles@813e9d2 There is still a lot of work/test before thinking to merge it into master.
|
@schabrolles Are these changes already merged? Or, are you waiting on my test results? I'm sorry, but I was too busy with other customer activities (cannot remember it anymore what I did). |
@gdha, everything is now merged. Just test it when you have time on your Ubuntu 16.04. It should work with or without set.ifnames=0 parameter. |
@schabrolles are you sure it is merged? I cannot find |
https://gist.github.com/gdha/408f266e446ee51bfb758e2ed9982d8d#file-rear-automated-test-sh-log-L117 proofs that the latest PR does its job properly - we're good to close this case |
In my rear-automated-testing environment (in centos7) I use the following entry to keep the network alias names with the kernel option:
See also the issue at gdha/rear-automated-testing#24
I used another local.conf file without the KERNEL_CMDLINE line, so we keep using the biosdevnames in client/server and recover VMs.
That is tedious and stupid, therefore, IMHO we better do some auto-detection of biosdevnames and
PS: this is also related to previous issues #951 and #1020
The text was updated successfully, but these errors were encountered: