vmware and interface names.
OK, this is turning out to be a huge problem a far as I can tell. I can't find any good info on this issue after searching the internet several times over the past few weeks.
My problem is that when I go to kickstart a RedHat 7.2 system I can never figure out what the interface names are going to be so I can't configure the static IP address on one and a dynamic IP address on another.
When I kickstart a system, I do it on a kickstart lan. The interface on that vlan is dynamic. There is another interface that is on the production lan, and I want to give that interface a specific IP address, but with the new "Simplified" ip address scheme I can never figure out what my IP addresses are going to be. I understand the thinking behind it, but without the ability to waist determine what the name of any given ethernet interface is going to be it becomes a pain in the butt, and this is a much more common occurrence that the problem they were hoping to resolve with this change.
So, Red Hat, if I am creating a new RedHat 7.2 VM on vmware esxi how do I discover what the ethernet interfaces are going to be before I build the system?
Is there a table somewhere that will allow me to work this out? I need help!
Thanks,
James "Zeke" Dehnert
--
James "Zeke" Dehnert
-= Eschew Obfuscation =-
"Life is racing. Everything else is just waiting"
Responses
As per guide here, i see that you could use MAC address bonded with network interface in kickstart file as --device=.. this should work.. 23.3. KICKSTART SYNTAX REFERENCE
8.1. NAMING SCHEMES HIERARCHY
By default, systemd will name interfaces using the following policy to apply the supported naming schemes:
Scheme 1: Names incorporating Firmware or BIOS provided index numbers for on-board devices (example: eno1), are applied if that information from the firmware or BIOS is applicable and available, else falling back to scheme 2.
Scheme 2: Names incorporating Firmware or BIOS provided PCI Express hotplug slot index numbers (example: ens1) are applied if that information from the firmware or BIOS is applicable and available, else falling back to scheme 3.
Scheme 3: Names incorporating physical location of the connector of the hardware (example: enp2s0), are applied if applicable, else falling directly back to scheme 5 in all other cases.
Scheme 4: Names incorporating interface's MAC address (example: enx78e7d1ea46da), is not used by default, but is available if the user chooses.
Scheme 5: The traditional unpredictable kernel naming scheme, is used if all other methods fail (example: eth0).
This policy, the procedure outlined above, is the default. If the system has biosdevname enabled, it will be used. Note that enabling biosdevname requires passing biosdevname=1 as a command-line parameter except in the case of a Dell system, where biosdevname will be used by default as long as it is installed. If the user has added udev rules which change the name of the kernel devices, those rules will take precedence.
How could I do that on VMs that are already up and running? And do I have to specify the optional MAC in my interfaces configuration file to do that?
I'm using a template to clone my red hat VMs. Most of my VMs only need one network interface. Until now all of my VMs have an interface name of "ens192". This is predictable and I got them up and running in short time.
Last week I upgraded the vm-hardware of one of my VMs from vmx-8 to vmx-11 and had to realize that the networking connection is broken because the inteface name changed to enoXXXXXXXX where X is a digit between 0.and 9. I figured out that when I specify the HWADDR option in the interface configuration file (ifcfg-ens192) before the vm-hardware upgrade the inteface name would not be changed. But I don't like the idea to specify this option every time I clone a VM.
Did anyone run into the same issues? How do you deal with it?
We have experienced the same problem with NIC naming on VMware particularly with the differences you have noted between different virtual hardware versions. Unfortunately this appears set to change again, from the RHEL7.3 beta release notes: "Shortening of long network device names Previously, some network devices could have unacceptably long names. This was due to certain firmware reporting meaningless data, such as onboard index, which the kernel passed to user-space. This resulted into problems with maximum name length, especially with VLANs. With this update, systemd rejects unacceptably long names and falls back to a different naming scheme. As a result, long network devices names will no longer appear, and names on existing installations might change. (BZ#1230210) "
Thus far it has been neither predicatable nor persistent.
I know it's not the cleanest way to solve this, but you can look at using Ansible to automate the higher step of VM creation. When creating a VM using vsphere_guest you can query the VM and extract the MAC address fairly easily before you boot.
The naming has caused some problems in our environments too when multiple NICs are configured.
The basic process is to define the VM then run vmware_guest_facts to pull the MAC address. There is an example of this in the Ansible documentation pages:
Regarding the NIC name change going from 7.2 to 7.3, this KB article has relevant info.
Good Morning,
Thank you, for your replies so far.
I've read the KB article mentioned by Akemi. From what I understood systemd-219-21.el7 or later will prevent ugly long names. But how would it affect the NICs in my scenario?
Today I stuck with hardware version vmx-8 to keep my pretty interface names (ens192). I guess there would be no change to the interface name if I upgrade to RHEL 7.3. Could anyone confirm that? Otherwise I would run some tests on my own and come back to you with the results.
Depending upon how you use kickstart, using ksdevice=link might help. It will configure on the first active NIC
Today, I have updated one of my test-vms to 7.3 with systemd-219-30.el7_3.3. The interface name is still ens192. After that I upgraded the vm hardware to vmx-11 and RHEL 7.3 kept the inteface name.
For me, that's good news. Now, I'm able to upgrade the vm-hardware without loosing my interface names.
Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.
