0 Replies Latest reply on May 8, 2014 12:31 PM by racerx90

    Interface device naming issue when using Linux guest with systemd udev

    racerx90 Novice

      I believe there's an issue with Fusion (and I think also with other VMware virtualization products) that shows up when using Linux guests utilizing systemd udev predictable device naming:

       

      looking at parent device '/devices/pci0000:00/0000:00:11.0/0000:02:01.0':

        KERNELS=="0000:02:01.0"

        SUBSYSTEMS=="pci"

        DRIVERS=="e1000"

        ATTRS{vendor}=="0x8086"

        ATTRS{device}=="0x100f"

        ATTRS{subsystem_vendor}=="0x15ad"

        ATTRS{subsystem_device}=="0x0750"

        ATTRS{class}=="0x020000"

        ATTRS{irq}=="19"

        ATTRS{local_cpus}=="00000000,0000000f"

        ATTRS{local_cpulist}=="0-3"

      ...

        ATTRS{label}=="Ethernet0"

        ATTRS{acpi_index}=="16777736"

       

      As you can see from the acpi_index above, 16777736 looks suspiciously like a negative error overflow.  As such, you end up with bizarre network interface name (eno16777736) when systemd udev renames the device:

       

      [ 93.973746] systemd-udevd[694]: renamed network interface eth0 to eno16777736

      [ 94.754129] e1000: eno16777736 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None

      [ 299.575432] e1000: eno16777736 NIC Link is Down

      [ 301.581982] e1000: eno16777736 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None

       

      Hopefully someone from VMware can weigh in on this as I'm fairly certain it's a bug with Fusion. Also, this isn't the first time this issue has come up either (just do an internet search and you'll find many references to the eno16777736 device renaming with VMware.)

       

      Here's a couple workarounds until this issue gets addressed:

       

      1. Create a custom rule based on the above output: /etc/udev/rules.d/79-my-net-name-slot.rules

       

      ACTION=="add", SUBSYSTEM=="net", ENV{ID_BUS}=="pci", KERNELS=="0000:02:01.0", NAME="eno1"

       

      2. Add net.ifnames=0 to the kernel boot options (grub) so the systemd device naming mechanism is disabled (it reverts back to using the old device naming mechanism, so you end up with "eth0" instead of an eno* named device.)