linux guest: weird NIC names "rename10", "rename11" ...

U

udotirol

Well-Known Member
Proxmox Subscriber
Mar 9, 2018
61
20
48
53
I've recently upgraded one of our installations from 6.x to the latest 7.x.

Because of that I have been monitoring the VMs a little bit more closely, which is why I noticed one linux VM behaving strangely. This is a debian 10 VM with more than 10 NICs and after closer inspection, I saw that a lot of interfaces have "lost" their name. They are now named as "rename9", "rename10" and so on:

Code: 
$ ip l
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: ens18: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
    link/ether b6:b6:98:b8:48:f5 brd ff:ff:ff:ff:ff:ff
3: ens19: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
    link/ether e6:7b:ba:fe:b1:b2 brd ff:ff:ff:ff:ff:ff
4: ens20: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
    link/ether ae:72:ff:51:e2:11 brd ff:ff:ff:ff:ff:ff
5: ens21: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
    link/ether 6a:15:c3:6e:e8:99 brd ff:ff:ff:ff:ff:ff
6: ens22: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
    link/ether 52:23:a6:bc:07:25 brd ff:ff:ff:ff:ff:ff
7: ens23: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
    link/ether f6:48:91:15:b3:df brd ff:ff:ff:ff:ff:ff
8: ens1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
    link/ether 06:53:d4:6f:81:02 brd ff:ff:ff:ff:ff:ff
9: rename9: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 66:11:21:99:2d:c1 brd ff:ff:ff:ff:ff:ff
10: ens30: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 96:66:9a:16:7c:e2 brd ff:ff:ff:ff:ff:ff
11: rename11: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether ae:9b:cd:1d:84:5d brd ff:ff:ff:ff:ff:ff
12: rename12: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 2e:20:dc:c4:34:96 brd ff:ff:ff:ff:ff:ff
13: rename13: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 6a:4c:66:09:a7:1d brd ff:ff:ff:ff:ff:ff

I am not 100% sure if this is related to the upgrade and even worse, I am 100% sure either if this hasn't been like that for a longer time, prior to the upgrade.

But maybe someone else has seen this before?

Thanks
 
hi,

can you check /usr/lib/systemd/network/99-default.link file in your VM?

also check journalctl -b to see any logged error messages since boot of the VM, dmesg can provider further hints as well.
 
PVE 7's kernel is no longer able to rename interfaces to keep 'eth0', 'eth1', 'eth2', etc consistent. This is primarily due to systemd initialising things concurrently.

If you want consistent names you now have to call them something other than what the kernel uses by default, the following example uses 'ether0'.

Code: 
Renaming network interfaces:
  pico /etc/default/grub
    Append the following to GRUB_CMDLINE_LINUX_DEFAULT: net.ifnames=0 biosdevname=0
  update-grub;
  pico /etc/systemd/network/9-vlan.link
    [Match]
    Type=vlan
    
    [Link]
    NamePolicy=kernel
  udevadm info /sys/class/net/eth0;
    ID_PATH=pci-0000_02_00_0
    MATCHADDR=00:1e:67:9b:f1:38
  rm -f /etc/udev/rules.d/70-persistent-net.rules;
  pico /etc/systemd/network/10-ether0.link
    [Match]
    MACAddress=00:1e:67:fd:06:bc
    Path=pci*
    
    [Link]
    Name=ether0
 
   Update initial ramdisk image:
    update-initramfs -u;

      # PS: Information matched from output from: udevadm info /sys/class/net/rename20
      #                                           udevadm info -a /sys/class/net/eth0
      #     Other Match examples:
      #       Driver=ixgbe
      #       Path=pci-0000:02:00.1
  perl -i -pe 's/eth(\d)/ether\1/g' /etc/network/interfaces;


Sample config files to get fixed network interface names:
Code: 
[root@kvm1b ~]# dir /etc/systemd/network
total 28
-rw-r--r-- 1 root root 67 Aug 30 22:08 10-ether0.link
-rw-r--r-- 1 root root 67 Aug 30 22:08 10-ether1.link
-rw-r--r-- 1 root root 67 Aug 30 22:08 10-ether2.link
-rw-r--r-- 1 root root 67 Aug 30 22:08 10-ether3.link
-rw-r--r-- 1 root root 67 Aug 30 22:08 10-ether4.link
-rw-r--r-- 1 root root 67 Aug 30 22:08 10-ether5.link
-rw-r--r-- 1 root root 44 Sep  9  2019 9-vlan.link
 
oguz said:
hi,

can you check /usr/lib/systemd/network/99-default.link file in your VM?

also check journalctl -b to see any logged error messages since boot of the VM, dmesg can provider further hints as well.
Click to expand...

here you go:

Code: 
$  cat /usr/lib/systemd/network/99-default.link
#  SPDX-License-Identifier: LGPL-2.1+
#
#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.
 
[Link]
NamePolicy=keep kernel database onboard slot path
MACAddressPolicy=persistent

I never touched the file.

What I did in the meantime was to disable the renaming of the network interfaces via /etc/default/grub:

Code: 
GRUB_CMDLINE_LINUX_DEFAULT="quiet net.ifnames=0"

AFAIK, dmesg didn't show anything suspicious, but I'll reenable the NIC renaming and reboot in the evening, when the VM is less used.
 
David Herselman said:
PVE 7's kernel is no longer able to rename interfaces to keep 'eth0', 'eth1', 'eth2', etc consistent. This is primarily due to systemd initialising things concurrently.

If you want consistent names you now have to call them something other than what the kernel uses by default, the following example uses 'ether0'.

Code: 
Renaming network interfaces:
  pico /etc/default/grub
    Append the following to GRUB_CMDLINE_LINUX_DEFAULT: net.ifnames=0 biosdevname=0
  update-grub;
  pico /etc/systemd/network/9-vlan.link
    [Match]
    Type=vlan
   
    [Link]
    NamePolicy=kernel
  udevadm info /sys/class/net/eth0;
    ID_PATH=pci-0000_02_00_0
    MATCHADDR=00:1e:67:9b:f1:38
  rm -f /etc/udev/rules.d/70-persistent-net.rules;
  pico /etc/systemd/network/10-ether0.link
    [Match]
    MACAddress=00:1e:67:fd:06:bc
    Path=pci*
   
    [Link]
    Name=ether0
 
   Update initial ramdisk image:
    update-initramfs -u;

      # PS: Information matched from output from: udevadm info /sys/class/net/rename20
      #                                           udevadm info -a /sys/class/net/eth0
      #     Other Match examples:
      #       Driver=ixgbe
      #       Path=pci-0000:02:00.1
  perl -i -pe 's/eth(\d)/ether\1/g' /etc/network/interfaces;


Sample config files to get fixed network interface names:
Code: 
[root@kvm1b ~]# dir /etc/systemd/network
total 28
-rw-r--r-- 1 root root 67 Aug 30 22:08 10-ether0.link
-rw-r--r-- 1 root root 67 Aug 30 22:08 10-ether1.link
-rw-r--r-- 1 root root 67 Aug 30 22:08 10-ether2.link
-rw-r--r-- 1 root root 67 Aug 30 22:08 10-ether3.link
-rw-r--r-- 1 root root 67 Aug 30 22:08 10-ether4.link
-rw-r--r-- 1 root root 67 Aug 30 22:08 10-ether5.link
-rw-r--r-- 1 root root 44 Sep  9  2019 9-vlan.link
Click to expand...
Thanks, but I highly doubt this has got anything to do with my issue. I'm talking about a linux guest (debian buster) running it's own kernel and I can't imagine the PV host kernel would interfere with the device renaming in a guest VM.
 
udotirol said:
I never touched the file.
Click to expand...
you can try moving that file from that path away and see if the interfaces are named correctly after a reboot of the VM
 
You must log in or register to reply here.

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Quick Navigation

Home Get Subscription Wiki Downloads Proxmox Customer Portal About

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!
Community platform by XenForo® © 2010-2024 XenForo Ltd.
Top Bottom