canonical / canonical/multipass
[hyper-v] Filter unsupported switches in "multipass networks"
- Dominant language
- C++
- Stars
- 9.2k
- Forks
- 828
- Avg merge
- 3d 1h
- Merged PRs (30d)
- 44
Description
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 https://github.com/canonical/multipass/pull/4080#discussion_r3119087016_
Contributor guide
Research direction
Start by tracing the old Hyper-V backend path that builds NetworkInterfaceInfo from switches and adapters, then inspect how multipass networks uses that result for display and bridging. Done means unsupported switches are omitted rather than retained with filtered links, and such switches are not considered for bridging.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp
- Domain
- networking, operating-systems
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100