Network Interface – Predictable Names Break VM Migration

network-interfacesystemd-networkd

How do you reset /etc/networking/interfaces when using "predictable network interface names"?

Versions of Ubuntu older than 15.10 use network adapter names like:

  • eth0
  • eth1
  • eth2

Replacing a network card, or moving a vm to a new hypervisor, would cause Linux to increment the interface number. Deleting /etc/udev/rules.d/70-peristent-net.rules would make Linux reuse eth0.

Ubuntu 15.10 and newer use 'Predictable Network Interface Names'. The network adapter name is derived from the mac address.

  • ens3
  • ens32
  • ens192

When migrating a vm, the networking won't start since /etc/network/interfaces still references the old non existent network adapter. 

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto ens32
iface ens32 inet dhcp
pre-up sleep 2

What's the best way to reset the /etc/network/interfaces file?

I need to do this action before shutting down the vm and migrating to a new hypervisor since I'm using packer to make automated golden images, based on the chef/bento golden images.

I've found deleting /etc/network/interfaces does not work since the file isn't automatically regenerated on the next boot after migration.

I've tried editing my grub file to revert back to the 'eth0' naming convention. While /etc/network/interfaces does refer to the old name (eth0), the vm will not get an ip, and any reboots will cause the vm to use the new naming convention. Also I've found systemd will always take precedence unless I can guarantee biosdevname=0 permanently remains in the grub config. Not sure how to permanently apply this

GRUB_CMDLINE_LINUX_DEFAULT="net.ifnames=0 bios.devname=0"

If possible, I'd rather not use cloud init or use any post startup scripts since I'd rather keep the golden images as clean as possible.

Surely this is a problem that cloud providers (Azure, AWS, RackSpace, Openstack) have already solved when they import vms. I can't possibly be the first person to try and migrate a vm using predictable network interface names.

I've tried running these commands before shutting down and migrating the vm

apt-get remove biosdevname -y;
ln -s /dev/null /etc/systemd/network/99-default.link;

I find when I migrate the vm, that /etc/network/interfaces and ip address still refer to ens32

Best Answer

Surely this is a problem that cloud providers (Azure, AWS, RackSpace, Openstack) have already solved when they import vms.

I think OpenStack uses cloud-init, ConfigDrive format, and provides a network configuration that matches the VM hardware. Sources:

If you rule out a first-boot script, there is one obvious answer.

Previously it was practically guaranteed that hosts equipped with a single ethernet card only had a single "eth0" interface. With this new scheme in place, an administrator now has to check first what the local interface name is before he can invoke commands on it where previously he had a good chance that "eth0" was the right name.

I don't like this, how do I disable this?

You basically have three options:

  1. You disable the assignment of fixed names, so that the unpredictable kernel names are used again. For this, simply mask udev's .link file for the default policy: ln -s /dev/null /etc/systemd/network/99-default.link

https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/

Switching back to the old persistent interface names is not one of the options documented.

The other alternative is a setup where network interfaces are enabled by default, regardless of their exact name. I think NetworkManager supports this by default. systemd-networkd can also be told to do this.

As soon as you have more than one network device for a VM, they probably need specific configuration anyway...

Outside of VM's, there is one obvious advantage of the NetworkManager-style approach: a PC might have multiple network interfaces, perhaps of different types, with only one of them being connected. For example this can be seen on some premium motherboards, or on a system where the first network interface did not work as desired and a second interface was installed at some point.

Related Question