If you’ve installed RHEL/CentOS 7, then you’ve probably encountered the now-default ‘consistent network device naming’ feature. The goal is to eliminate what, in theory, is the unpredictable nature of network interface names on Linux. I get it, I’ve experienced the issue it’s designed to fix.  Two examples:

• I added a quad-port NIC to a PCIe slot on a server that had two on-board NICs.  Apparently on this server the add-on card PCIe bus came before the bus the onboard NICs were attached to, so my then-current eth0 and eth1 became eth4 and eth5.
• On a server with the NIC MAC addresses hard coded in the ifcfg-eth* files to prevent the above issue from occurring, I replaced a dead NIC and of course the interfaces didn’t come up because the MACs had changed.

CNDN ‘fixes’ this issue by basing the interface name on one of five options in this order:

1. If the server’s firmware or BIOS gives the OS a number for the NIC, it will use that.  For example, if the port on the back of the server is labeled 1, the BIOS can report that as “1” to the OS, and it will become eno1 regardless of any other ports you add or remove from the system.
2. If the server doesn’t support the above, the name will be based on the PCIe hotplug slot, if the server provides that.
3. If the server doesn’t support either of those, the hardware location of the NIC will be used.
4. If you choose to enable option 4, you can have the NIC name based on the MAC address, which is of course pointless and stupid.
5. Go back to the traditional “unpredictable” naming scheme.

In reality, who isn’t using virtual machines these days?  CNDN fixes an issue that stopped being an issue for most people years ago, and complicates things for most new installs in the process.  I deploy thousands of virtual machines on top of Vmware vSphere.  They nearly all get one NIC.  The NIC is always eth0.  How hard is that?  Well, with RHEL 7, now my NIC’s get stupid names like eno16780032 because that’s “better.”  Every VM comes up with a different name, so from one day to the next, you’ll have no clue what interface names your new builds may use.  Every config management and deployment script that was built around knowing the NIC would be named eth0 now needs to be rewritten.

Redhat’s answer is of course, if you don’t like it, “simply” go back to the old way.  Well simple means appending kernel args (biosdevname=0 net.ifnames=0), adding the same to GRUB_CMDLINE_LINUX in /etc/default/grub, regenerating the grub config (grub2-mkconfig -o /boot/grub2/grub.cfg), adding a symlink (ln -s /dev/null /etc/udev/rules.d/80-net-name-slot.rules), rebooting then fixing all of your interface files and anything else referencing the old name.  Yeah, that’s simple.  You’re also doing so with the caveat that they *may* require you to use the new network manager at some point; goodie. Here’s a reasonable thread on this: https://access.redhat.com/discussions/916973

So with that being said, lets say you’d like to go ahead and deal with the stupidity and build your VM’s using network manager with ‘consistent’ names.  Well, how do you kick start those servers when the network directive needs a device name?  Seems like a catch 22 with VM’s since you’re guaranteed to get an inconsistent random name with each new server.  An example solution is the following shell script placed in the %pre section of your kickstart config, and then referencing the $interface variable wherever needed in the rest of the config:

%include /tmp/network.ks

%pre
ip addr | grep -i broadcast | awk '{ print $2 }' > /tmp/interface
sed -i 's/:/\ /g' /tmp/interface
interface=`cat /tmp/interface`
echo "network --bootproto static --device $interface --ip 192.0.2.2 --netmask 255.255.255.0 --gateway 192.0.2.1 --nodns --nameserver=192.0.2.3" >/tmp/network.ks
echo "network --hostname=newserver" >>/tmp/network.ks
%end