Hello All,
I have one CentOS 6 KVM virtualization server that I built around a year ago (best I can tell it was in October 2012) at which time I would have been installing 6.3 [0]. That particular install used the Consistent Network Device Naming [1] conventions (PCIe NICs are p1p1, p1p2).
I started to build out a new KVM virt server (kickstarting a 6.4 install now as compared to 6.3 back then) and the interface names are back to the old ethX convention for the PCIe NICs. See below for my snippets from udev persistent rules on the two hosts.
I'm working off of [older] Dell PowerEdge 2950 hardware that has dual onboard Broadcom NICs and an additional Intel Dual GigE PCIe NIC.
** Did anyone but me notice this change/regression in network interface naming? ** Does anyone know if or why a change was made from what 6.3 or earlier apparently defaulted to?
This is by no means a major problem, but it did make me wonder what caused or why there was a change. [Of course I can change interface names in the udev rules if I chose to.]
Thanks for your feedback!
==================
Snippets:
# was 6.3 when initially installed, but has been updated to 6.4 since then ~]# cat /etc/*ele* CentOS release 6.4 (Final) CentOS release 6.4 (Final) CentOS release 6.4 (Final) cpe:/o:centos:linux:6:GA ~]# egrep -v '^$|^#' /etc/udev/rules.d/70-persistent-net.rules SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:22:19:xx:xx:xx", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0" SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:22:19:xx:xx:xx", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1" SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:15:17:xx:xx:xx", ATTR{type}=="1", KERNEL=="eth*", NAME="p1p1" SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:15:17:xx:xx:xx", ATTR{type}=="1", KERNEL=="eth*", NAME="p1p2" ~]# lspci | grep Ether 05:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5708 Gigabit Ethernet (rev 12) 09:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5708 Gigabit Ethernet (rev 12) 0c:00.0 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (rev 06) 0c:00.1 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (rev 06)
# freshly installed 6.4 ~]# cat /etc/*ele* CentOS release 6.4 (Final) CentOS release 6.4 (Final) CentOS release 6.4 (Final) cpe:/o:centos:linux:6:GA ~]# egrep -v '^$|^#' /etc/udev/rules.d/70-persistent-net.rules SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:22:19:xx:xx:xx", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0" SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:15:17:xx:xx:xx", ATTR{type}=="1", KERNEL=="eth*", NAME="eth2" SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:22:19:xx:xx:xx", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1" SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:15:17:xx:xx:xx", ATTR{type}=="1", KERNEL=="eth*", NAME="eth3" ~]# lspci | grep Ether 03:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5708 Gigabit Ethernet (rev 12) 07:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5708 Gigabit Ethernet (rev 12) 08:00.0 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (rev 06) 08:00.1 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (rev 06)
[0] https://access.redhat.com/site/articles/3078 [1] https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/...
On 11/15/2013 01:50 PM, SilverTip257 wrote:
Hello All,
I have one CentOS 6 KVM virtualization server that I built around a year ago (best I can tell it was in October 2012) at which time I would have been installing 6.3 [0]. That particular install used the Consistent Network Device Naming [1] conventions (PCIe NICs are p1p1, p1p2).
I started to build out a new KVM virt server (kickstarting a 6.4 install now as compared to 6.3 back then) and the interface names are back to the old ethX convention for the PCIe NICs. See below for my snippets from udev persistent rules on the two hosts.
I'm working off of [older] Dell PowerEdge 2950 hardware that has dual onboard Broadcom NICs and an additional Intel Dual GigE PCIe NIC.
** Did anyone but me notice this change/regression in network interface naming? ** Does anyone know if or why a change was made from what 6.3 or earlier apparently defaulted to?
This is by no means a major problem, but it did make me wonder what caused or why there was a change. [Of course I can change interface names in the udev rules if I chose to.]
Thanks for your feedback!
==================
Snippets:
# was 6.3 when initially installed, but has been updated to 6.4 since then ~]# cat /etc/*ele* CentOS release 6.4 (Final) CentOS release 6.4 (Final) CentOS release 6.4 (Final) cpe:/o:centos:linux:6:GA ~]# egrep -v '^$|^#' /etc/udev/rules.d/70-persistent-net.rules SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:22:19:xx:xx:xx", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0" SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:22:19:xx:xx:xx", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1" SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:15:17:xx:xx:xx", ATTR{type}=="1", KERNEL=="eth*", NAME="p1p1" SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:15:17:xx:xx:xx", ATTR{type}=="1", KERNEL=="eth*", NAME="p1p2" ~]# lspci | grep Ether 05:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5708 Gigabit Ethernet (rev 12) 09:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5708 Gigabit Ethernet (rev 12) 0c:00.0 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (rev 06) 0c:00.1 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (rev 06)
# freshly installed 6.4 ~]# cat /etc/*ele* CentOS release 6.4 (Final) CentOS release 6.4 (Final) CentOS release 6.4 (Final) cpe:/o:centos:linux:6:GA ~]# egrep -v '^$|^#' /etc/udev/rules.d/70-persistent-net.rules SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:22:19:xx:xx:xx", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0" SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:15:17:xx:xx:xx", ATTR{type}=="1", KERNEL=="eth*", NAME="eth2" SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:22:19:xx:xx:xx", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1" SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:15:17:xx:xx:xx", ATTR{type}=="1", KERNEL=="eth*", NAME="eth3" ~]# lspci | grep Ether 03:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5708 Gigabit Ethernet (rev 12) 07:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5708 Gigabit Ethernet (rev 12) 08:00.0 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (rev 06) 08:00.1 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (rev 06)
[0] https://access.redhat.com/site/articles/3078 [1] https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/...
Do you have the biosdevname package loaded?
On Fri, Nov 15, 2013 at 01:50:18PM -0500, SilverTip257 wrote:
Hello All,
I have one CentOS 6 KVM virtualization server that I built around a year ago (best I can tell it was in October 2012) at which time I would have been installing 6.3 [0]. That particular install used the Consistent Network Device Naming [1] conventions (PCIe NICs are p1p1, p1p2).
This regression is a combo RedHat/Dell idea, IIRC. That may be why it's that way on a Dell machine. On Fedora, which usually shows what new regressions will be in RH, it's gotten harder to fix with each iteration.
To make it worse, at least on Fedora (and again, many of their ideas, whether good or bad for servers, get into RedHat) has apparently now been intertwined with systemd. At first, one simply had to remove the biosdevnames rpm to fix it. Now, one has to do that, and also add, (in Fedora, with grub2) net.ifnames=0 to the kernel line. (Note that this was for Fedora 19, not sure if they at least removed biosdevnames in F20).
To make it even more of a mess, (again, this is judging from Fedora, which is good to keep on hand to see what new decisions good and bad will be made by RH), I think biosdevnames gave it one name and then the whole systemd thing gave it another. So, it would boot up as say p12p but in /etc/sysconfig/network-scripts it would show up as ifcfg-p1p2p or something like that. (I'm making these names up, but that was the general idea.)
Some people consider it a good thing, especially when moving drives between machines, but aside from it being something new, which isn't necessarily improved, it breaks various working scripts.
Like you, I consider it a regression, but of course, that's only my opinion, and many experienced folks disagree, thinking it's a good thing--although I'm sure that even they would agree that they better figure out if biosdevname or something else will be handling it so that it is at least consistent.
Actually, I think (but am not sure, that in VMs, even Fedora will use the eth0, eth1 system rather than the new naming scheme. Not just KVM, but also VirtualBox, VMware, and so on--that has been my experience with CentOS VMs at least.
On Fri, Nov 15, 2013 at 2:33 PM, Scott Robbins scottro@nyc.rr.com wrote:
On Fri, Nov 15, 2013 at 01:50:18PM -0500, SilverTip257 wrote:
Hello All,
I have one CentOS 6 KVM virtualization server that I built around a year ago (best I can tell it was in October 2012) at which time I would have been installing 6.3 [0]. That particular install used the Consistent Network Device Naming [1] conventions (PCIe NICs are p1p1, p1p2).
This regression is a combo RedHat/Dell idea, IIRC. That may be why it's that way on a Dell machine. On Fedora, which usually shows what new regressions will be in RH, it's gotten harder to fix with each iteration.
To make it worse, at least on Fedora (and again, many of their ideas, whether good or bad for servers, get into RedHat) has apparently now been intertwined with systemd. At first, one simply had to remove the biosdevnames rpm to fix it. Now, one has to do that, and also add, (in Fedora, with grub2) net.ifnames=0 to the kernel line. (Note that this was for Fedora 19, not sure if they at least removed biosdevnames in F20).
I'm not tied to wanting my network interfaces to be ethX. Once my servers are configured, I'm generally not changing anything, so for all it matters they could be called wan0, etc.
I actually think some of the conventions are worthwhile (ex: em for embedded, pXpY for PCI cards - I've not seen any others on Fedora/CentOS). I believe embedded NIC naming on Dell hw starts with em1 rather than em0 which is odd (we start counting at zero!).
To make it even more of a mess, (again, this is judging from Fedora, which is good to keep on hand to see what new decisions good and bad will be made by RH), I think biosdevnames gave it one name and then the whole systemd thing gave it another. So, it would boot up as say p12p but in /etc/sysconfig/network-scripts it would show up as ifcfg-p1p2p or something like that. (I'm making these names up, but that was the general idea.)
I did see something similar to this, I believe it was on a Fedora system I was using for testing ... I don't recall which release though.
RHEL7 ought to have some "Easter eggs" for us. ;)
Some people consider it a good thing, especially when moving drives between machines, but aside from it being something new, which isn't necessarily improved, it breaks various working scripts.
Like you, I consider it a regression, but of course, that's only my opinion, and many experienced folks disagree, thinking it's a good thing--although I'm sure that even they would agree that they better figure out if biosdevname or something else will be handling it so that it is at least consistent.
I'm not calling the biosdevname conventions a regression. But what I am calling a regression is all the flip flopping between the old convention and the new one, especially on two nearly identical hardware builds and OS builds for that matter.
Actually, I think (but am not sure, that in VMs, even Fedora will use the eth0, eth1 system rather than the new naming scheme. Not just KVM, but also VirtualBox, VMware, and so on--that has been my experience with CentOS VMs at least.
-- Scott Robbins PGP keyID EB3467D6 ( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 EB34 67D6 ) gpg --keyserver pgp.mit.edu --recv-keys EB3467D6
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
/etc/udev/rules.d/70-persistent-net.rules is your friend
the device names defined in there are set nice and early during boot, well before any ifcfg scripts
K
Kahlil (Kal) Hodgson GPG: C9A02289 Head of Technology (m) +61 (0) 4 2573 0382 DealMax Pty Ltd (w) +61 (0) 3 9008 5281
Suite 1415 401 Docklands Drive Docklands VIC 3008 Australia
"All parts should go together without forcing. You must remember that the parts you are reassembling were disassembled by you. Therefore, if you can't get them together again, there must be a reason. By all means, do not use a hammer." -- IBM maintenance manual, 1925
On 16 November 2013 10:12, SilverTip257 silvertip257@gmail.com wrote:
On Fri, Nov 15, 2013 at 2:33 PM, Scott Robbins scottro@nyc.rr.com wrote:
On Fri, Nov 15, 2013 at 01:50:18PM -0500, SilverTip257 wrote:
Hello All,
I have one CentOS 6 KVM virtualization server that I built around a year ago (best I can tell it was in October 2012) at which time I would have been installing 6.3 [0]. That particular install used the Consistent Network Device Naming [1] conventions (PCIe NICs are p1p1, p1p2).
This regression is a combo RedHat/Dell idea, IIRC. That may be why it's that way on a Dell machine. On Fedora, which usually shows what new regressions will be in RH, it's gotten harder to fix with each iteration.
To make it worse, at least on Fedora (and again, many of their ideas, whether good or bad for servers, get into RedHat) has apparently now been intertwined with systemd. At first, one simply had to remove the biosdevnames rpm to fix it. Now, one has to do that, and also add, (in Fedora, with grub2) net.ifnames=0 to the kernel line. (Note that this was for Fedora 19, not sure if they at least removed biosdevnames in F20).
I'm not tied to wanting my network interfaces to be ethX. Once my servers are configured, I'm generally not changing anything, so for all it matters they could be called wan0, etc.
I actually think some of the conventions are worthwhile (ex: em for embedded, pXpY for PCI cards - I've not seen any others on Fedora/CentOS). I believe embedded NIC naming on Dell hw starts with em1 rather than em0 which is odd (we start counting at zero!).
To make it even more of a mess, (again, this is judging from Fedora, which is good to keep on hand to see what new decisions good and bad will be made by RH), I think biosdevnames gave it one name and then the whole systemd thing gave it another. So, it would boot up as say p12p but in /etc/sysconfig/network-scripts it would show up as ifcfg-p1p2p or something like that. (I'm making these names up, but that was the general idea.)
I did see something similar to this, I believe it was on a Fedora system I was using for testing ... I don't recall which release though.
RHEL7 ought to have some "Easter eggs" for us. ;)
Some people consider it a good thing, especially when moving drives between machines, but aside from it being something new, which isn't necessarily improved, it breaks various working scripts.
Like you, I consider it a regression, but of course, that's only my opinion, and many experienced folks disagree, thinking it's a good thing--although I'm sure that even they would agree that they better figure out if biosdevname or something else will be handling it so that it is at least consistent.
I'm not calling the biosdevname conventions a regression. But what I am calling a regression is all the flip flopping between the old convention and the new one, especially on two nearly identical hardware builds and OS builds for that matter.
Actually, I think (but am not sure, that in VMs, even Fedora will use the eth0, eth1 system rather than the new naming scheme. Not just KVM, but also VirtualBox, VMware, and so on--that has been my experience with CentOS VMs at least.
-- Scott Robbins PGP keyID EB3467D6 ( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 EB34 67D6 ) gpg --keyserver pgp.mit.edu --recv-keys EB3467D6
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
-- ---~~.~~--- Mike // SilverTip257 // _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Mon, Nov 25, 2013 at 4:08 PM, Kahlil Hodgson kahlil.hodgson@dealmax.com.au wrote:
/etc/udev/rules.d/70-persistent-net.rules is your friend
the device names defined in there are set nice and early during boot, well before any ifcfg scripts
If you clone a multi-homed KVM guest or copy the underlying disk image, is there some way to tie the interface names on the guest to the same host bridge devices (or at least something known) so you'll know which ifcfg-* file gets which address?
On Mon, Nov 25, 2013 at 5:08 PM, Kahlil Hodgson < kahlil.hodgson@dealmax.com.au> wrote:
/etc/udev/rules.d/70-persistent-net.rules is your friend
the device names defined in there are set nice and early during boot, well before any ifcfg scripts
Precisely.
Something changed between 6.3 and 6.4 and devices reverted from pXpY to ethX naming conventions.
In the past I've modified the persistent net rules as necessary.
Thanks.
K
Kahlil (Kal) Hodgson GPG: C9A02289 Head of Technology (m) +61 (0) 4 2573 0382 DealMax Pty Ltd (w) +61 (0) 3 9008 5281
Suite 1415 401 Docklands Drive Docklands VIC 3008 Australia
"All parts should go together without forcing. You must remember that the parts you are reassembling were disassembled by you. Therefore, if you can't get them together again, there must be a reason. By all means, do not use a hammer." -- IBM maintenance manual, 1925
On 16 November 2013 10:12, SilverTip257 silvertip257@gmail.com wrote:
On Fri, Nov 15, 2013 at 2:33 PM, Scott Robbins scottro@nyc.rr.com
wrote:
On Fri, Nov 15, 2013 at 01:50:18PM -0500, SilverTip257 wrote:
Hello All,
I have one CentOS 6 KVM virtualization server that I built around a
year
ago (best I can tell it was in October 2012) at which time I would
have
been installing 6.3 [0]. That particular install used the Consistent Network Device Naming [1] conventions (PCIe NICs are p1p1, p1p2).
This regression is a combo RedHat/Dell idea, IIRC. That may be why it's that way on a Dell machine. On Fedora, which usually shows what new regressions will be in RH, it's gotten harder to fix with each
iteration.
To make it worse, at least on Fedora (and again, many of their ideas, whether good or bad for servers, get into RedHat) has apparently now
been
intertwined with systemd. At first, one simply had to remove the biosdevnames rpm to fix it. Now, one has to do that, and also add, (in Fedora, with grub2) net.ifnames=0 to the kernel line. (Note that this
was
for Fedora 19, not sure if they at least removed biosdevnames in F20).
I'm not tied to wanting my network interfaces to be ethX. Once my servers are configured, I'm generally not changing anything, so
for
all it matters they could be called wan0, etc.
I actually think some of the conventions are worthwhile (ex: em for embedded, pXpY for PCI cards - I've not seen any others on
Fedora/CentOS).
I believe embedded NIC naming on Dell hw starts with em1 rather than em0 which is odd (we start counting at zero!).
To make it even more of a mess, (again, this is judging from Fedora,
which
is good to keep on hand to see what new decisions good and bad will be
made
by RH), I think biosdevnames gave it one name and then the whole systemd thing gave it another. So, it would boot up as say p12p but in /etc/sysconfig/network-scripts it would show up as ifcfg-p1p2p or
something
like that. (I'm making these names up, but that was the general idea.)
I did see something similar to this, I believe it was on a Fedora system
I
was using for testing ... I don't recall which release though.
RHEL7 ought to have some "Easter eggs" for us. ;)
Some people consider it a good thing, especially when moving drives
between
machines, but aside from it being something new, which isn't necessarily improved, it breaks various working scripts.
Like you, I consider it a regression, but of course, that's only my opinion, and many experienced folks disagree, thinking it's a good thing--although I'm sure that even they would agree that they better
figure
out if biosdevname or something else will be handling it so that it is
at
least consistent.
I'm not calling the biosdevname conventions a regression. But what I am calling a regression is all the flip flopping between the
old
convention and the new one, especially on two nearly identical hardware builds and OS builds for that matter.
Actually, I think (but am not sure, that in VMs, even Fedora will use
the
eth0, eth1 system rather than the new naming scheme. Not just KVM, but also VirtualBox, VMware, and so on--that has been my experience with
CentOS
VMs at least.
-- Scott Robbins PGP keyID EB3467D6 ( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 EB34 67D6 ) gpg --keyserver pgp.mit.edu --recv-keys EB3467D6
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
-- ---~~.~~--- Mike // SilverTip257 // _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
-
Kahlil Hodgson -
Les Mikesell -
Scott Robbins -
SilverTip257 -
Steve Clark