LinuxQuestions.org
Latest LQ Deal: Latest LQ Deals
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Red Hat
User Name
Password
Red Hat This forum is for the discussion of Red Hat Linux.

Notices


Reply
  Search this Thread
Old 08-22-2019, 12:39 PM   #1
bkannadassan
LQ Newbie
 
Registered: Sep 2017
Posts: 10

Rep: Reputation: Disabled
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
 
Old 08-22-2019, 10:32 PM   #2
berndbausch
Senior Member
 
Registered: Nov 2013
Location: Tokyo
Distribution: Redhat/Centos, Ubuntu, Raspbian, Fedora, Alpine, Cirros, OpenSuse/SLES
Posts: 3,287

Rep: Reputation: 859Reputation: 859Reputation: 859Reputation: 859Reputation: 859Reputation: 859Reputation: 859
Quote:
Originally Posted by bkannadassan View Post
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.
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).
 
Old 08-22-2019, 11:38 PM   #3
permaroot
Member
 
Registered: Aug 2019
Location: Arden, NC
Distribution: Manjaro, Centos7, Arch
Posts: 105

Rep: Reputation: 46
Quote:
Originally Posted by berndbausch View Post
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.

Last edited by permaroot; 08-22-2019 at 11:39 PM.
 
Old 08-23-2019, 10:20 AM   #4
bkannadassan
LQ Newbie
 
Registered: Sep 2017
Posts: 10

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by berndbausch View Post
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).
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

Last edited by bkannadassan; 08-23-2019 at 10:43 AM.
 
Old 08-23-2019, 10:30 AM   #5
bkannadassan
LQ Newbie
 
Registered: Sep 2017
Posts: 10

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by permaroot View Post
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.
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.
Quote:
[root@hng-sriov1 ~]# ls /etc/sysconfig/network-scripts/
ifcfg-eth0 ifdown-ipv6 ifdown-tunnel ifup-ipv6 ifup-routes network-functions-ipv6
ifcfg-lo ifdown-isdn ifup ifup-isdn ifup-sit
ifdown ifdown-post ifup-aliases ifup-plip ifup-tunnel
ifdown-bnep ifdown-ppp ifup-bnep ifup-plusb ifup-wireless
ifdown-eth ifdown-routes ifup-eth ifup-post init.ipv6-global
ifdown-ippp ifdown-sit ifup-ippp ifup-ppp network-functions
[root@hng-sriov1 ~]# ls /etc/sysconfig/network-scripts/
[root@hng-sriov1 ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
BOOTPROTO=none
ONBOOT=yes
TYPE=Ethernet
USERCTL=yes
PEERDNS=yes
IPV6INIT=no
PERSISTENT_DHCLIENT=1
Please find attached picture showing the same..

rgds
Balaji Kamal Kannadassan
Attached Thumbnails
Click image for larger version

Name:	Screenshot - 23-08-2019  11_00_11 (003).png
Views:	2
Size:	88.5 KB
ID:	31194  

Last edited by bkannadassan; 08-23-2019 at 10:41 AM.
 
Old 08-23-2019, 11:25 AM   #6
bkannadassan
LQ Newbie
 
Registered: Sep 2017
Posts: 10

Original Poster
Rep: Reputation: Disabled
Quote:
Failed dmesg log: Here eth0 goes to vf interface
--------------------------------------------------
[ 4.202972] igbvf 0000:00:07.0: irq 27 for MSI/MSI-X
[ 4.203019] igbvf 0000:00:07.0: irq 28 for MSI/MSI-X
[ 4.203071] igbvf 0000:00:07.0: irq 29 for MSI/MSI-X
[ 4.226564] igbvf 0000:00:07.0: Intel(R) I350 Virtual Function
[ 4.230121] igbvf 0000:00:07.0: Address: fa:16:3e:fb:38:64
[ 4.234019] igbvf 0000:00:08.0: irq 30 for MSI/MSI-X
[ 4.234065] igbvf 0000:00:08.0: irq 31 for MSI/MSI-X
[ 4.234112] igbvf 0000:00:08.0: irq 32 for MSI/MSI-X
[ 4.257565] igbvf 0000:00:08.0: Intel(R) I350 Virtual Function
[ 4.261427] igbvf 0000:00:08.0: Address: fa:16:3e:43:21:0c
[ 4.333315] virtio-pci 0000:00:05.0: irq 33 for MSI/MSI-X
[ 4.333342] virtio-pci 0000:00:05.0: irq 34 for MSI/MSI-X
[ 4.334176] virtio-pci 0000:00:03.0: irq 35 for MSI/MSI-X
[ 4.334217] virtio-pci 0000:00:03.0: irq 36 for MSI/MSI-X
[ 4.334273] virtio-pci 0000:00:03.0: irq 37 for MSI/MSI-X
[ 4.337829] virtio-pci 0000:00:04.0: irq 38 for MSI/MSI-X
[ 4.337866] virtio-pci 0000:00:04.0: irq 39 for MSI/MSI-X
[ 4.337902] virtio-pci 0000:00:04.0: irq 40 for MSI/MSI-X

Passing dmesg log: Here eth0 goes to virtio and no issues
---------------------------------------------------------

[ 3.834155] virtio-pci 0000:00:03.0: irq 24 for MSI/MSI-X
[ 3.834193] virtio-pci 0000:00:03.0: irq 25 for MSI/MSI-X
[ 3.834251] virtio-pci 0000:00:03.0: irq 26 for MSI/MSI-X
[ 3.837443] virtio-pci 0000:00:04.0: irq 27 for MSI/MSI-X
[ 3.837472] virtio-pci 0000:00:04.0: irq 28 for MSI/MSI-X
[ 3.837511] virtio-pci 0000:00:04.0: irq 29 for MSI/MSI-X
[ 3.838977] virtio-pci 0000:00:05.0: irq 30 for MSI/MSI-X
[ 3.839021] virtio-pci 0000:00:05.0: irq 31 for MSI/MSI-X
[ 6.825764] piix4_smbus 0000:00:01.3: SMBus Host Controller at 0x700, revision 0
[ 6.842837] igbvf 0000:00:06.0: irq 32 for MSI/MSI-X
[ 6.843005] igbvf 0000:00:06.0: irq 33 for MSI/MSI-X
[ 6.843327] igbvf 0000:00:06.0: irq 34 for MSI/MSI-X
[ 6.886674] igbvf 0000:00:06.0: Intel(R) I350 Virtual Function
[ 6.892103] igbvf 0000:00:06.0: Address: fa:16:3e:34:f1:8d
[ 6.908700] igbvf 0000:00:07.0: irq 35 for MSI/MSI-X
[ 6.908741] igbvf 0000:00:07.0: irq 36 for MSI/MSI-X
[ 6.908780] igbvf 0000:00:07.0: irq 37 for MSI/MSI-X
[ 6.938258] igbvf 0000:00:07.0: Intel(R) I350 Virtual Function
[ 6.942187] igbvf 0000:00:07.0: Address: fa:16:3e:54:64:b8
[ 6.966885] igbvf 0000:00:08.0: irq 38 for MSI/MSI-X
[ 6.969472] igbvf 0000:00:08.0: irq 39 for MSI/MSI-X
[ 6.969524] igbvf 0000:00:08.0: irq 40 for MSI/MSI-X
[ 6.996735] igbvf 0000:00:08.0: Intel(R) I350 Virtual Function
[ 6.996737] igbvf 0000:00:08.0: Address: fa:16:3e:e7:38:8a
[ 7.030431] igbvf 0000:00:09.0: irq 41 for MSI/MSI-X
[ 7.030479] igbvf 0000:00:09.0: irq 42 for MSI/MSI-X
[ 7.030551] igbvf 0000:00:09.0: irq 43 for MSI/MSI-X
[ 7.054560] igbvf 0000:00:09.0: Intel(R) I350 Virtual Function
[ 7.060122] igbvf 0000:00:09.0: Address: fa:16:3e:5e:2f:8c
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
 
Old 08-23-2019, 06:30 PM   #7
berndbausch
Senior Member
 
Registered: Nov 2013
Location: Tokyo
Distribution: Redhat/Centos, Ubuntu, Raspbian, Fedora, Alpine, Cirros, OpenSuse/SLES
Posts: 3,287

Rep: Reputation: 859Reputation: 859Reputation: 859Reputation: 859Reputation: 859Reputation: 859Reputation: 859
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.

Last edited by berndbausch; 08-23-2019 at 06:44 PM.
 
Old 09-11-2019, 08:22 AM   #8
bkannadassan
LQ Newbie
 
Registered: Sep 2017
Posts: 10

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by berndbausch View Post
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

Last edited by bkannadassan; 09-11-2019 at 08:24 AM.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
Persistent Naming of a Block Device CentOS 6 bluefish1 Linux - Server 9 10-05-2012 08:05 PM
Persistent persistent Persistent Going Nuts Here Fcukinyahoo Linux - Newbie 6 11-17-2011 09:56 PM
Changing UDEV persistent naming schemes orbit Slackware 5 04-21-2008 09:22 PM
Is there a way to have grub translate its own naming to naming scheme under Linux zhjim Linux - Software 6 05-28-2006 08:09 AM
mail server the naming naming convention problem kashan Linux - Newbie 0 07-16-2004 02:08 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Red Hat

All times are GMT -5. The time now is 06:17 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration