vmware and interface names.

Latest response

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.

It's true, the MAC addresses can be used, but thats not really something that I can automate very easily. When you create the basic VM in the VMware interface, it doesn't even give you the MAC address. You have to save the VM configuration, then go back to the configuration, select the hardware, then go to each interface and then copy down the MAC addresses. Pre Red Hat 7 I didn't need to do any of that to build a new system. The basic VM could be created, then I could run a script to create the kickstart configuration and then pxeboot that VM and have it build itself. With the new "simplified" ethernet naming, that just can't be done.

I am hoping to learn how to build the VM from the command line so I can automate that part too. If I do that I may be able to pull the MAC addresses out to use on my scripts.

There is also the "inst.ks.sendmac" pxeboot option. If you add that to the boot string the system will send back string that looks like this:

    X-RHN-Provisioning-MAC-0: eth0 01:23:45:67:89:ab

Unfortunately, you need to use tcpdump or tcpflow to capture that info. I'm trying to figure out how to do that in the pre execution script so I can pass the interface names and the mac address names (if I still need them) to the kickstart configuration files . I have seen no examples of anyone doing this yet, but I'm still looking and tinkering.

I just hope Red Hat figures out how to make this work much, much more easily when building VM's. I probably build 20 VM's for every physical box I build these days, and I don't see that changing in the physical box's favor any time soon. In the mean time, its a pain to kickstart VM's because you never know what the interface name is going to pop up as.

If you are running VMware, you may even disable the new naming scheme, because there is no use of it. It is useful only for the physical boxes...

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:

http://docs.ansible.com/ansible/vsphere_guest_module.html

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.

Close

Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.