CentOS/RHEL and wrong Network Interface
This is a quick entry on a particularly irritating CentOS peculiarity – after you clone a virtual machine, your /etc/sysconfig/network-scripts/ifcfg-eth0 no longer gets invoked. This is because CentOS can arbitrarily assign the physical network card to a different logic interface such as eth1. Read on for a quick tutorial on how to identify and fix this problem.
Many times after provisioning CentOS box you will notice that ifconfig -a doesn’t show the connected vSphere network adapter:
Take a look closely at the above drawing. The logical eth1 interface has no network traffic (no RX received or TX transmitted packets), and there is certainly no IP address. However, I know for a fact that this VM – before cloning – had the logical eth1 interface properly bound to the physical network card (NIC) presented by VMware to the guest OS (eth0).
So what happened??
Many of you already know this, but CentOS / RHEL can (and do!) arbitrarily reassign a “physical” network adapter (MAC address) to a new interface (“ethX“). By default we expect the network adapter to be assigned to eth0 and we have /etc/sysconfig/network-scripts/ifcfg-eth0 – in the above shot, CentOS assigned the VMware-presented “physical” network adapter to eth1. (It’s always best to put quotes around that word “physical” when you’re talking about a virtualized environment!) Thus…no network connectivity!
There are many ways to fix this problem: create a new file /etc/sysconfig/network-scripts/ifcfg-eth1 to match the CentOS values, run ifconfig commands manually to set this value, or update the udev files to force CentOS to use the desired interface.
For this blog entry, let’s take the third approach and update the udev file to fix this problem: first, locate and edit /etc/udev/rules.d/70-persistent-net.rules and modify as shown in the screenshot below:
Look at the shot above: Do you see the circled area? In the original template VM, this file had eth0 as the named PCI device (via the NAME element from the screenshot). However, the *cloned* VM had that value replaced with eth1. (Maybe a CentOS / RHEL expert can share with us the logic behind this action…all I know is that it happens, not *why* it happens!)
To fix this problem: Find the interface in the udev file and modify the NAME variable to be eth0 as indicated above. While at it, open /etc/sysconfig/network-scripts/ifcfg-eth0 and verify that no MAC address is specified. This allows the system to auto-bind to the correct interface. Then reboot the VM and all should be well:
Ah – now we see that our eth1 interface has the IP address 172.24.7.249 assigned to it which is exactly what we wanted. Victory!
Hope you all enjoyed this quick article, let me know if you have any questions or comments.
Team-oriented systems mentor with deep knowledge of numerous software methodologies, technologies, languages, and operating systems. Excited about turning emerging technology into working production-ready systems. Focused on moving software teams to a higher level of world-class application development. Specialties:Software analysis and development...Product management through the entire lifecycle...Discrete product integration specialist!
This reply from David Little on the Linked-In CentOS group discussion (http://www.linkedin.com/groupItem?view=&gid=22405&type=member&item=272565976&qid=90d8126c-b909-4e96-8667-84c63ea4d27b&trk=groups_most_popular-0-b-ttl&goback=%2Egde_22405_member_272565976%2Egmp_22405):
“RHEL/CentOS will assign an interface number when a new NIC is added to the system. It already had an eth0 so it created eth1 when the clone was kicked off, then VMware deletes the original interface but it doesn’t update anything in the guest OS.
I think the best way to work around this if you do a lot of cloning is to just have an RHEL template without network adapters and then post customization scripting for network configuration.”
Thanks David!
In Centos 7 new variable NAME appeared in /etc/sysconfig/network-scripts/ifcfg-enp13s0. Does anybody know what does it mean?