Persistent Naming in Centos 7 help!
 

Hi All,

We have Centos 7 QCOW cloud image system and we have disabled consistent naming setting biosdevname and netnames to 0 in grub and did grub makeconfig. We now see only eth0/1/2... but the problem we face is soemtimes MAC to eth0/1/2 changes and not the same on different reboots.Please let us know if there is a way to get around the same.

rgds
Balaji

I'd say if you remove persistent naming, you can't expect names to persist.

However, you can still use udev to rename interfaces according to their MAC address. You'll find instructions on the internet, for example https://www.shellhacks.com/change-ne...th0-eth1-eth2/ (Disclaimer: I can't vouch for the correctness of this page).

Might be a good idea for the OP to post the config of /etc/sysconfig/network-scripts/[nic name]



The udev persistent file probably isn’t applied if that option is disabled?


If the mac addressed defined in network-scripts stays the same on every boot but the Mac assigned to the nic is different, it might help narrow down the problem.

And if the hardware address isn’t defined by default in that file, adding it may solve the problem.

Thanks for the same, please note we haven't been doing for the qcow2 which we built from centos7.iso. We have disable biosdevname and netnames to 0. When we did this we could see ethX names started appearing in interfaces as expected. But the problem is on each boot ethX keeps moving to different MAC.

https://www.freedesktop.org/wiki/Sof...nterfaceNames/

When I referred above link it was said

The classic naming scheme for network interfaces applied by the kernel is to simply assign names beginning with "eth0", "eth1", ... to all interfaces as they are probed by the drivers. As the driver probing is generally not predictable for modern technology this means that as soon as multiple network interfaces are available the assignment of the names "eth0", "eth1" and so on is generally not fixed anymore and it might very well happen that "eth0" on one boot ends up being "eth1" on the next. This can have serious security implications, for example in firewall rules which are coded for certain naming schemes, and which are hence very sensitive to unpredictable changing names.

Now this is ok until the same happens in all qcow, but why this difference between one created from iso and one created from cloud image of centos. Hence we are hoping there should be a solution to change the order of probing i.e to probe in the order shown in lspci. Please note

1) When qcow created from iso using virt-install issue not seen
2) When qcow created from Centos cloud image qcow inconsistency in mapping on every reboot

Sorry for not adding more information, we haven't specified MAC address and we don't have a persistent file in network-scripts. This is on a qcow build as explained above and issue seen when qcow created from Centos7 qcow build using diskimage builder and not seen when qcow created from Centos7 iso using virt-install. I have done some more debugging on this and found..

lspci: This is correct order.
ifconfig: Assigned eth0 to 2nd ethernet in lspci and eth1 to 1st ethernet in lspci.

Please note this happens when we attach SRIOV port. What I came to know is interfaces are probed and interfaces are assigned in that order of probing. If so why lspci and eth are out of order.
Please find attached picture showing the same..

rgds
Balaji Kamal Kannadassan

Please find as above some more information on my debugging, I see in failed system vf driver came up first and eth0 was assigned to sriov port. In passed system we could see virtio driver was first to comeup and eth0 was assigned to proper interface.

rgds
Balaji Kamal Kannadassan

I think it's situations like yours that predictable interface naming is supposed to fix. But if my application must have interfaces named eth0 and eth1, I would configure predictable names and use udev to change the name of the SRIOV interface (the virtio interface should have eth0 already).

Why do the two VMs discover the NICs in a different order? Obviously their kernels or some aspects of kernel environment are different. You could try to find out what the differences are, but it sounds like a tedious job.

EDIT: Suggestions how to use udev to solve your problem: https://serverfault.com/questions/61...ork-interfaces. In short, create udev rules that base NIC names on the PCI addresses.

EDIT2: Since your VMs seem to be running in an OpenStack cloud, you could try cloudinit to inject those udev rules upon first boot rather than adding them manually.

We don't want to use udev rules rather allow consistent naming and we have solved as below. Btw just to let others who face such issue.

https://docs.openstack.org/diskimage...es/README.html

This element when included while building qcow via diskimage builder will provide consistent naming as per lspci.
What this does is remove the null reference of persistent rules in /etc/udev/rules.d and by default biosdevname and net.ifnames are enabled..

rgds
Balaji Kamal Kannadassan