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:
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
Ubuntu 15.10 and newer use 'Predictable Network Interface Names'. The network adapter name is derived from the mac address.
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'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
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
ip address still refer to