In the old Hyper-V backend, this received the adapters to make sure that the interface "links" were part of the final set of networks. IOW, the NetworkInterfaceInfo of a switch with adapter X would only include X in its links if there was another NetworkInterfaceInfo for X in the adapters.
The idea was to avoid dealing with any adapters other than Ethernet. However, looking back at it, the proper measure would probably be to skip such switches entirely, rather than keeping them with filtered links. That would avoid, for example, multipass networks showing vSwitches linked to a Wi-Fi adapter while omitting the Wi-Fi cards themselves. It would also prevent multipass from ever considering such a switch for bridging: it would just complain it didn't know the network.
So, in the future, should this filter unsupported switches? WDYT?
Originally posted by @ricab in #4080 (comment)
In the old Hyper-V backend, this received the adapters to make sure that the interface "links" were part of the final set of networks. IOW, the
NetworkInterfaceInfoof a switch with adapter X would only include X in its links if there was another NetworkInterfaceInfo for X in the adapters.The idea was to avoid dealing with any adapters other than Ethernet. However, looking back at it, the proper measure would probably be to skip such switches entirely, rather than keeping them with filtered links. That would avoid, for example,
multipass networksshowing vSwitches linked to a Wi-Fi adapter while omitting the Wi-Fi cards themselves. It would also prevent multipass from ever considering such a switch for bridging: it would just complain it didn't know the network.So, in the future, should this filter unsupported switches? WDYT?
Originally posted by @ricab in #4080 (comment)