RE: Strange network device name chages on reboot of SL7 kvm guests
Thanks everyone for your comments and advice. It seemed I had commented out the HWADDR and UUID for some strange reason. I have now added them back in and all is back to normal. Now I know the importance of those values. Cheers Bill -Original message- > From:~Stack~ <i.am.st...@gmail.com> > Sent: Monday 27th February 2017 1:58 > To: SCIENTIFIC-LINUX-USERS@FNAL.GOV > Subject: Re: Strange network device name chages on reboot of SL7 kvm guests > > On 02/25/2017 10:18 PM, Bill Maidment wrote: > > Hi again > Greetings! > > > I have recently rebooted KVM guests with two virtual NICs (e.g. /dev/ens4 > > and /dev/eth0) only to find that the device name of the eth0 changes to > > eth1 and so the ifcfg-eth0 doesn't match. > > So I fix the ifcfg file and restart network - all OK. > > On a later reboot eth1 changes back to eth0. > > What is going on? Anyone else observe this phenomena? > > Yes. It is part of the goofy new naming structure. It's nice when it > works, but it seems to not-work more often then it does-work. Then it is > infuriating. > > > Anyway... > > Here's the short version. > en: ethernet prefix > o: onboard > s: slot > p: physical location of connector. > > If the device is "unknown" then it gets "eth". And of course the numbers > increment for each new device. > > So what your device names tell me is that you have one card in slot 4 > and a second card that the OS can't figure out where it goes. > > There are two ways of "fixing" this. > 1) > *If* you have your HWADDR= assigned in your > /etc/sysconfig/network-scripts/ifcfg-eth0 then it *should* always get > that interface regardless of what the OS detects it to be on boot. I > have found this isn't always the case with some specialty cards that > take FOREVER to initialize. I tend to throw in the UUID as well and that > seems to resolve the problems for those cards. > > 2) > Now, here is the odd part because this next problem is also on my big > KVM host. None of the above worked. I never found a good answer to why > and I am wondering if it is related to KVM...but at this point my sample > size is two so probably not something to make a solid educated guess on... > > Anyway.. > > Read this: > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Networking_Guide/ch-Consistent_Network_Device_Naming.html > > There are some good tips throughout chapter 8 on how to tweak and/or > disable udev from scanning devices. I had to rewrite the udev rules on > my KVM box right after 7.1 released because *every* *single* reboot > broke my networking. However, after I adjusted the udev rules based on > the RH documentation I haven't had a problem with reboots since. > > I _really_ hope that #1 fixes your issues as it is by far the easiest to > do and manage. If not, the udev rules should do the trick. > > One last thought. In that documentation there is something called > "biosdevname"; I'm pretty sure that wasn't in the docs when I was having > a problem with 7.1 as I don't recall seeing it before, but it looks > interesting. You might just want to go through that chapter and give > those suggestions a go. > > Hope that helps! > > ~Stack~ > >
Re: Strange network device name chages on reboot of SL7 kvm guests
On 26/02/17 15:57, ~Stack~ wrote: > One last thought. In that documentation there is something called > "biosdevname"; I'm pretty sure that wasn't in the docs when I was having > a problem with 7.1 as I don't recall seeing it before, but it looks > interesting. You might just want to go through that chapter and give > those suggestions a go. IIRC, biosdevname was already introduced in some RHEL6 release, but only enabled on Dell hardware. And it was further extended to be used more widely in RHEL7. The biosdevname package seems to be installed by default at least. On my servers I usually rename interfaces to indicate which network segment the interface belongs to (through HWADDR= in ifcfg-*). But on all my EL7 based laptops, both the wireless and physical Ethernet cards uses the new naming scheme. -- kind regards, David Sommerseth
Re: Strange network device name chages on reboot of SL7 kvm guests
In FermiCloud we have stripped out all of the udev stuff in our VM images to avoid having to deal with this. I would suggest you do the same. Steve From: owner-scientific-linux-us...@listserv.fnal.gov <owner-scientific-linux-us...@listserv.fnal.gov> on behalf of ~Stack~ <i.am.st...@gmail.com> Sent: Sunday, February 26, 2017 8:57:30 AM To: scientific-linux-users Subject: Re: Strange network device name chages on reboot of SL7 kvm guests On 02/25/2017 10:18 PM, Bill Maidment wrote: > Hi again Greetings! > I have recently rebooted KVM guests with two virtual NICs (e.g. /dev/ens4 and > /dev/eth0) only to find that the device name of the eth0 changes to eth1 and > so the ifcfg-eth0 doesn't match. > So I fix the ifcfg file and restart network - all OK. > On a later reboot eth1 changes back to eth0. > What is going on? Anyone else observe this phenomena? Yes. It is part of the goofy new naming structure. It's nice when it works, but it seems to not-work more often then it does-work. Then it is infuriating. Anyway... Here's the short version. en: ethernet prefix o: onboard s: slot p: physical location of connector. If the device is "unknown" then it gets "eth". And of course the numbers increment for each new device. So what your device names tell me is that you have one card in slot 4 and a second card that the OS can't figure out where it goes. There are two ways of "fixing" this. 1) *If* you have your HWADDR= assigned in your /etc/sysconfig/network-scripts/ifcfg-eth0 then it *should* always get that interface regardless of what the OS detects it to be on boot. I have found this isn't always the case with some specialty cards that take FOREVER to initialize. I tend to throw in the UUID as well and that seems to resolve the problems for those cards. 2) Now, here is the odd part because this next problem is also on my big KVM host. None of the above worked. I never found a good answer to why and I am wondering if it is related to KVM...but at this point my sample size is two so probably not something to make a solid educated guess on... Anyway.. Read this: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Networking_Guide/ch-Consistent_Network_Device_Naming.html There are some good tips throughout chapter 8 on how to tweak and/or disable udev from scanning devices. I had to rewrite the udev rules on my KVM box right after 7.1 released because *every* *single* reboot broke my networking. However, after I adjusted the udev rules based on the RH documentation I haven't had a problem with reboots since. I _really_ hope that #1 fixes your issues as it is by far the easiest to do and manage. If not, the udev rules should do the trick. One last thought. In that documentation there is something called "biosdevname"; I'm pretty sure that wasn't in the docs when I was having a problem with 7.1 as I don't recall seeing it before, but it looks interesting. You might just want to go through that chapter and give those suggestions a go. Hope that helps! ~Stack~
Re: Strange network device name chages on reboot of SL7 kvm guests
On 02/25/2017 10:18 PM, Bill Maidment wrote: > Hi again Greetings! > I have recently rebooted KVM guests with two virtual NICs (e.g. /dev/ens4 and > /dev/eth0) only to find that the device name of the eth0 changes to eth1 and > so the ifcfg-eth0 doesn't match. > So I fix the ifcfg file and restart network - all OK. > On a later reboot eth1 changes back to eth0. > What is going on? Anyone else observe this phenomena? Yes. It is part of the goofy new naming structure. It's nice when it works, but it seems to not-work more often then it does-work. Then it is infuriating. Anyway... Here's the short version. en: ethernet prefix o: onboard s: slot p: physical location of connector. If the device is "unknown" then it gets "eth". And of course the numbers increment for each new device. So what your device names tell me is that you have one card in slot 4 and a second card that the OS can't figure out where it goes. There are two ways of "fixing" this. 1) *If* you have your HWADDR= assigned in your /etc/sysconfig/network-scripts/ifcfg-eth0 then it *should* always get that interface regardless of what the OS detects it to be on boot. I have found this isn't always the case with some specialty cards that take FOREVER to initialize. I tend to throw in the UUID as well and that seems to resolve the problems for those cards. 2) Now, here is the odd part because this next problem is also on my big KVM host. None of the above worked. I never found a good answer to why and I am wondering if it is related to KVM...but at this point my sample size is two so probably not something to make a solid educated guess on... Anyway.. Read this: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Networking_Guide/ch-Consistent_Network_Device_Naming.html There are some good tips throughout chapter 8 on how to tweak and/or disable udev from scanning devices. I had to rewrite the udev rules on my KVM box right after 7.1 released because *every* *single* reboot broke my networking. However, after I adjusted the udev rules based on the RH documentation I haven't had a problem with reboots since. I _really_ hope that #1 fixes your issues as it is by far the easiest to do and manage. If not, the udev rules should do the trick. One last thought. In that documentation there is something called "biosdevname"; I'm pretty sure that wasn't in the docs when I was having a problem with 7.1 as I don't recall seeing it before, but it looks interesting. You might just want to go through that chapter and give those suggestions a go. Hope that helps! ~Stack~ signature.asc Description: OpenPGP digital signature
Strange network device name chages on reboot of SL7 kvm guests
Hi again I have recently rebooted KVM guests with two virtual NICs (e.g. /dev/ens4 and /dev/eth0) only to find that the device name of the eth0 changes to eth1 and so the ifcfg-eth0 doesn't match. So I fix the ifcfg file and restart network - all OK. On a later reboot eth1 changes back to eth0. What is going on? Anyone else observe this phenomena? Cheers Bill Maidment
