Thanks Aviegas! We are also working on solution for this case, and script you mentioned should be help on the case. Thanks again for your sharing.
I have noticed that the driver only advertises 1000/Full as supported. Is this normal?
Thanks for the feedback! We are considering to expand the advertised list in next release. You know, the speed for USB networking adaptors not only related to MAC/PHY but also related to USB BUS speed. If you plug a USB Gagibit networking adaptor on USB3, you got 1000M, while if you plug it on USB2, you will get 100M+, as USB2 is on speed 480M.
Two questions: Is there an "ideal" USB Ethernet adapter from a performance and stability perspective? Or too early to call?
Also: Do I need to be worried about USB controller support in ESXi? I'm running 6.7U1 on a NUC7PJYH and I have no idea if it can even see the USB hardware in this unit. Gemini Lake/June Canyon is not a popular VMware platform for obvious reasons...
Thanks for asking!
Regarding to USB Ethernet adapters, we tested several USB Gigabit Network adaptors which using AX88179 and RTL8153 chipsets on USB3.0 ports , the performance basically similar, it maybe vary between different's vendors' products.
For USB controllers, we support USB 3.0 and USB 2.0 natively. I do not have NUC7PJYH, but by a quick search, it has USB2.0 and USB3.0 ports, it should be plug and play in theory. Let me know if you see any issues. Thanks!
Try:
esxcli hardware pci list | more
And slowly check for the USB controller. Per the NUC7PJYH specs external USB ports are 3.0, so you can use the AX88179 or RTL8153 based cards.
I do not think there is enough benchmark data at this time to point to a better card, except that from the specs, the RTL8153 is 9K jumbo frame capable while the AX88179 cannot go beyond 4K jumbo frames. I say may because the drivers may not allow it and I do not have access to the RTL8153 to test. But if jumbo frames is not an issue for you, either one will do it at this time,
Just found one really interesting thing when using multiple adapters, that should happen with dual/combo or when using discrete adapters: the assigned network name can vary.
I only can imagine that the adapters timing are not deterministic and they show up to the kernel at different times.
As the kernel cannot persist the device name, the only approach I can think of is to use the MAC address in the RC script to properly assign the devices/uplinks to the correct networks/portgroups. I will try to get it to work and I will post whatever script I come up with.
Something like:
Loop to wait for all interfaces
Get MAC of interface
Assign to virtual switch and portgroup based on MAC not on interface name.