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.)
