Getting eth0 back in a SLES for VMware clone

It’s almost effortless to use vCenter Server to create customized clones of virtual machines.  VMware vSphere is the only virtualization platform that has fully integrated Linux guest customization — a handy wizard allows setting unique attributes of the guest such as name, static IP address, timezone, and DNS settings.  That means the your new VM is deployed and ready for action without additional configuration.

After cloning a Linux VM, you might find your network interface is no longer named eth0, taking on eth1 instead.  Fortunately, this doesn’t cause any functional problems with the guest and can be left as-is.  However, if you are not satisfied with this scenario, read on…

SLES for VMware, which is SLES 11 SP1, uses udev to provide persistency to various devices.  While this model is regarded by most as a big step forward from the semi-random device name assignments of the past, one side-effect is that a new MAC address — pertinent when cloning VMs — is regarded as an additional interface and not a replacement.  Thus, a newly-cloned SLES VM powers up with eth1 as the NIC name, not eth0.

Fortunately, this situation is easy to fix.  Simply log into the VM and edit:

Which should look something like this:

In the above example, the first line contains the MAC address of the original template VM and the second line is the new NIC/MAC found in the clone.

There are two ways to fix this issue:

  • Completely delete the file — it will be created again on boot and the first NIC will be assigned eth0, OR
  • Delete the line containing the old entry that references eth0 and change “eth1” to “eth0” in the remaining line.

Note: if a static IP has been configured, go to /etc/sysconfig/network/ and update the files ifcfg-eth0 and route accordingly.

Reboot the VM and verify that the NIC(s) are named to your liking.

No real breaking news here, but given the newly available SLES for VMware, some evaluators may run into this situation.

Tags: , , ,

6 comments

  1. Brad Clarke’s avatar

    Works for older Ubuntu and Debian as well, though Debian called the file z25_persistent-net.rules.

    Newer Debian and Ubuntu will detect VMWare MAC addresses and not write them to the file in the first place to avoid this problem.

    1. Eric Gray’s avatar

      Good to know, thanks.

    2. Christian’s avatar

      Thx, very easy solution.

    3. Richard’s avatar

      Thanks, this helped a lot.

    4. Beto’s avatar

      Thx. Your tip saved my neck. Greetings from Brasil.

    5. Stefan’s avatar

      Thanks, that helped me building my packer template. I just remove the persisted value in my packer build, so the Vagrant boxes can use eth0 in our vCloud.

Comments are now closed.