In Rocky 8 VM (hypervisor is also Rocky 8) "first " network interface is ksdev0, the “second” is enp4s0. I thought both of them should be en*.
There is nothing special about how they are defined (virt-install command below). Also there is nothing special in libvirt domain file (below).
Is there anything I can do enforce the en* naming?
virt_install_command: "virt-install --name {{ next_server_name }}
--ram=2048 --vcpus=2
--os-type {{ tmp_virt_ostype }} --os-variant {{ tmp_virt_osvariant }}
--disk {{ next_server_name }}.qcow2,pool=vm,bus=virtio,size=10,format=qcow2
{% for net in net_config -%}
{% for net_type in vm_net_type if net_type.name == net.name -%}
--network network:net-ovs-br0,mac={{ net.mac }},portgroup=vlan-{{ net_type.vlan }}
{% endfor -%}
{% endfor -%}
--location {{ tmp_virt_iso }}
--nographics --noautoconsole --watchdog default
--initrd-inject {{ kickstart_file }}
--extra-args='inst.ks=file:/{{ next_server_name }}.ks console=ttyS0,115200n8'"
<interface type='network'>
<mac address='52:54:00:a0:2b:60'/>
<source network='net-ovs-br0' portgroup='vlan-6'/>
<model type='virtio'/>
<address type='pci' domain='0x0000' bus='0x02' slot='0x00' function='0x0'/>
</interface>
<interface type='network'>
<mac address='52:54:00:b0:2b:60'/>
<source network='net-ovs-br0' portgroup='vlan-22'/>
<model type='virtio'/>
<address type='pci' domain='0x0000' bus='0x03' slot='0x00' function='0x0'/>
</interface>
I have found the guilty party:
/etc/systemd/network/10-anaconda-ifname-ksdev0.link
Anaconda installer is placing configuration file for systemd-networkd.
But the system is using network manager (and networkd is not even installed)…
Interface names like “enp5s0” are normal on RHEL 8.4, even on bare metal.
RHEL 7 had already predictable names on metal. CentOS 7 VM’s still get “eth*” names, which aren’t predictable.
OT: There were/is extra twist. Anaconda installer configures connections. It does bind the connection to device by MAC address, rather than the name of the device. When you create connection with nmcli you must use the name of device. It is possible to modify connection later to bind with MAC, not name. How did I learn this? I had C7 VM with three manually defined connections. Every second boot had net down, for the “eth*” names were truly random and config was bound to those names … except for the one connection that the installer had generated.
So, it is anaconda installer renaming the network interface (title updated).
Instead of figuring out why anaconda is doing that (like sane person would do), I resorted to red herring workaround: I created dummy interface for anaconda to rename, and than I removed that interface.
Problem solved.
In kickstart file I match interfaces with MAC address:
network --device={{ net.mac }} --bootproto=static --activate --onboot=on --noipv6 --ip={{ net.ip }} --netmask=255.255.0.0 --gateway={{ gw }} --nameserver={{ ns } --hostname={{ tmp_ks_hostname }}
Extra twist is that anaconda is placing configuration file for systemd-networkd (at least that is my understanding). But systemd-networkd is not installed, so how this is applied?
Removing the file in kickstart (in %post) solves naming issue, but than the interface is not configured…
/etc/systemd/network/10-anaconda-ifname-ksdev0.link
How about package NetworkManager-config-server?
Description : This adds a NetworkManager configuration file to make it behave more
: like the old "network" service. In particular, it stops NetworkManager
: from automatically running DHCP on unconfigured ethernet devices, and
: allows connections with static IP addresses to be brought up even on
: ethernet devices with no carrier.
:
: This package is intended to be installed by default for server
: deployments.
Nice find.
But this package provides only one file:
/usr/lib/NetworkManager/conf.d/00-server.conf
that disables by default the DHCP on unconfigured interfaces.
Since I am using static IP this does not help me.
What could help is to stop using kickstart’s network command, and configure network interfaces with nmcli in the kickstart’s %post section. But that means parsing nmcli output…
What if … you leave the --activate out and have --onboot=no? You could even have it with default DHCP config, but since it will never been started …
That does not help (–no-activate --onboot=no on both interfaces)…
There are 2 interfaces. The “first” one still gets renamed to ksdev0, and then renamed back - except its “correct” configuration stays in the ksdev0 connection profile.
The “Wired connection 1” profile is a default DHCP
[a@a ~]$ ip a s
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 52:54:00:a0:4e:60 brd ff:ff:ff:ff:ff:ff
inet 10.6.255.110/16 brd 10.6.255.255 scope global dynamic noprefixroute enp3s0
valid_lft 6174sec preferred_lft 6174sec
inet6 fe80::9a55:18b8:ef75:a4b8/64 scope link noprefixroute
valid_lft forever preferred_lft forever
3: enp4s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 52:54:00:b0:4e:60 brd ff:ff:ff:ff:ff:ff
[a@a ~]$ nmcli d s
DEVICE TYPE STATE CONNECTION
enp3s0 ethernet connected Wired connection 1
enp4s0 ethernet disconnected --
lo loopback unmanaged --
[a@a ~]$ nmcli c s
NAME UUID TYPE DEVICE
Wired connection 1 05cbf7c0-40b7-3a5e-b8ec-5e7a7694ad1d ethernet enp3s0
enp4s0 503de7d2-fe5d-45d4-ac2e-561641c06a25 ethernet --
ksdev0 a748ee03-c68e-4e2c-ac53-bd5ad50ba45c ethernet --