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:

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

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