If a NIC or VF will be added to the VyOS in Hyper-V, it will not be processed properly, which could lead to wrong interface enumeration and not-usable interfaces.
The problems exist because the virtual function in Hyper-V is not used directly - instead, hv_netvsc create a new one virtual NIC on VMBUS and bind VF to it as a slave. So, all the packets must be transferred via this virtual NIC, and VF should be simply ignored by the system.
How it looks now:
eth0 - paravirtualized NIC (VMBUS), master eth1 - VF NIC, slave rename3 - paravirtualized NIC (VMBUS) 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000 link/ether 00:0d:3a:8f:58:c2 brd ff:ff:ff:ff:ff:ff 3: rename3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether 00:0d:3a:8f:58:c2 brd ff:ff:ff:ff:ff:ff 4: eth1: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master eth0 state UP mode DEFAULT group default qlen 1000 link/ether 00:0d:3a:98:9f:c4 brd ff:ff:ff:ff:ff:ff [partially cutted output] ethtool -i eth0 driver: hv_netvsc bus-info: ethtool -i eth1 driver: mlx4_en bus-info: b26f:00:02.0 ethtool -i rename3 driver: hv_netvsc bus-info:
Also, you may see here that MAC addresses assigned incorrectly after all.
We need to detect such MASTER/SLAVE usage and ignore / do not use slave interfaces in the configuration.