Network issue after cloning Centos 6 VM


After cloning a Centos 6.5 VM I discovered that the first active NIC was not the expected eth0; instead eth1 was active.

Delving further into the network setup, I found there was no ifcfg-eth1 file.

This prevented me from assigning an IP address for eth1.

This problem is solved by fixing the mismatch between the udev 70-persistent-net.rules file and the corresponding ifcfg-ethX file.



When I looked at the network setup this was what I found.


Clone VM setup is missing ifcfg-ethx file for the active NIC

$ ifconfig -a

eth1 Link encap:Ethernet HWaddr 00:50:56:33:78:52

inet6 addr: fe80::250:56ff:fe33:7852/64 Scope:Link


RX packets:0 errors:0 dropped:0 overruns:0 frame:0

TX packets:39 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:1000

RX bytes:0 (0.0 b) TX bytes:12570 (12.2 KiB)

lo Link encap:Local Loopback

<deleted output>


$ ls /etc/sysconfig/network-scripts/ifcfg*

ifcfg-eth0 ifcfg-lo


How networking is assigned during cloning of a VM

The reason for this strange behavior lies in what happens when VMware creates the clone host.

Vmware (I am using Workstation 11) generates a new MAC for the clone VM NICs but it also retains the old network setup.

Linux manages devices (disks, usb devices, network cards) dynamically via events from the kernel sent to the udev daemon.

Events reported to udev include situations when a dev is added, removed or has changed state – up/down.

udev utilises certain files which contain rules to check and assign properties and values to devices it discovers.


Looking at the udev file

For this problem the relevant udev file is found in /etc/udev/rules.d/70-persistent-net.rules

Let’s have a look at the file.

$ ls /etc/udev/rules.d/70*

70-persistent-cd.rules 70-persistent-net.rules


$ cd /etc/udev/rules.d

$ cat 70-persistent-net.rules

# This file was automatically generated by the /lib/udev/write_net_rules

# program, run by the persistent-net-generator.rules rules file.


# You can modify it, as long as you keep each rule on a single

# line, and change only the value of the NAME= key


# PCI device 0x8086:0x100f (e1000)

SUBSYSTEM==”net”, ACTION==”add”, DRIVERS==”?*”, ATTR{address}==”00:0c:29:c4:20:ea”, ATTR{type}==”1″, KERNEL==”eth*”, NAME=”eth0″


# PCI device 0x8086:0x100f (e1000)

SUBSYSTEM==”net”, ACTION==”add”, DRIVERS==”?*”, ATTR{address}==”00:0c:29:26:46:3e”, ATTR{type}==”1″, KERNEL==”eth*”, NAME=”eth1″

Without digging too deeply, you get a sense that this file pertains to networking (clue SUBSYSTEM==”net”) and assigns the interface # (clue NAME=”eth0″) based on matching the mac address (clue ATTR{address}==”00:0c:29:c4:20:ea”).

Since the mac address for eth0 is historical (from the original machine) it will not match the new mac address generated via the cloning process.

As a result the new NIC gets a different eth interface # i.e. eth1.

Fixing ifcfg-eth1

Therefore  I had to create the ifcfg-eth1 file to assign an IP configuration to eth1.

This can be done simply by copying the ifcfg-eth0 file and editing and saving it as ifcfg-eth1.


It is important to delete the HWADDR and NAME settings from the ifcfg-eth1.

This is the result of the newly created ifcfg-eth1 file.

# cat /etc/sysconfig/network-scripts/ifcfg-eth1












Reboot the VM.

Reassign the new mac address to eth0

If you prefer to use eth0 rather than a randomly assigned ethX; the easiest way to correct this is to force the VM to re-read the device.

This can be done by:

Deleting the HWADDR, NAME, UUID entries from the existing ifcfg-eth0 file.

Deleting the 70-persistent-net.rules file from the /etc/udev/rules.d directory.

Reboot the VM.