I'm found that you may need to reload the management daemons to get it to show properly (and logout/login), so at the end of the script add:
/etc/init.d/hostd restart
/etc/init.d/vpxa restart
That did it! Thanks @aviegas.
Probably should update the instructions for those homelab folks that may not be using vsphere on a ESXI host.
Also, in the script it seems to have an elaborate waiting period to wait for the link status to be up before assigning it to a vswitch. But is that necessary? If you just want it to stay assigned to a vSwitch and not to have to wait for assignment just because of no link status? Just curious.
In my view there are 2 problems were.
The first, the reason for the script to wait for a link up, is to ensure that the kernel has recognized the USB NICs. They are not identified as early in the boot process (that is the reason for the script). The more complex part is that the USB device recognition is non-deterministic, that's why with multiple NICS the device naming may change from boot to boot.
The second problem is that, in the current driver implementation, the devices is flagged *Always* as UP! Even without a cable connected. That is why as soon as the USB stack identifies the device and creates the vusbx interface, the loop will exit.
If the device driver once change the to allow link up/down detection, then the script can be adapted not to look for an UP condition, but rather to detect the existence of the vusbx device.
Thanks for the feedback!
For the first case, would you please try to re-login the GUI to see if the configration updated? The hostd may not update the info when you check GUI. For the 2nd, please check the instruction scripts to build the configuraton, before a final solution.
For iSCSI there must be additionally rescan of iSCSI adapter and before this some delay/sleep (I tried with 15s):
sleep 15
esxcli storage core adapter rescan --adapter <iSCSI adapter name>
Also, the -M switch command is in some aspect strange ( esxcfg-vswitch -M ${if0} -p "<portgroup name>" vSwitch0 ). It works also without it, but not when using iSCSI. Without it iSCSI vmkernel adapter becomes uncompliant. Its strange, I have no idea why it works in this way, but it works.
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.
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.
Hey guys, thanks for this! I have a little problem where when I use the esxcfg-vswitch command to add the usb device as an uplink it seems to perform correctly but doesn't show in the gui as the uplink is in the vswitch. yet if i put a vm in the port group the network is functional. any reason why the gui doesn't reflect this? FYI - I created the vswitch and portgroup in the gui originally to note that the config doesn't stick on a reboot. Am i doing something wrong?
-m