Show virtual interface's TAP device #1077
Conversation
|
Updated pixels |
skobyda
force-pushed
the
tapDevice
branch
3 times, most recently
from
3503023
to
b31df61
Compare
|
Line coverage is related to the code I just moved around, not anything I added in this PR. Tests have only known flakes |
|
Ready for code review |
| @@ -105,6 +105,55 @@ VmNetworkActions.propTypes = { | |||
| networks: PropTypes.array.isRequired, | |||
| }; | |||
|
|
|||
| const NetworkSource = ({ network, networkId, vm, hostDevices }) => { | |||
| const id = vmId(vm.name); | |||
| const checkDeviceAviability = (network) => { | |||
There was a problem hiding this comment.
"Aviability" means checking if the device can fly, right?
The typo already exists in the moved code, it's just a funny typo.
|
Made the IP address column consistent with the source column. Horizontal
Horizontal Fuild
Vertical
|
|
@garrett Updated the PR to fluid: |
And this is how it looks with mobile:
|
|
Dropdown doesn't work correctly, that needs fix |
skobyda
force-pushed
the
tapDevice
branch
8 times, most recently
from
bc6440a
to
afec49a
Compare
Network interfaces that are attached to VMs have a TUN/TAP device. If you want to check manually, e.g. why the device is not working correctly, you need to know the interface name. Name of the tap device is be specified with attribute of the <target> element. If no target dev is specified upon vnic attachement, libvirt will create a new standard tap device with a name of the pattern "vnetN" Shot this device in the list of VM's interfaces. In the future, we could also allow user to choose/name a tap device during vNIC attachement. Fixes cockpit-project#1047
| return () => { | ||
| if (source !== null && checkDeviceAvailability(source)) { | ||
| cockpit.jump(`/network#/${source}`, cockpit.transport.host); |
There was a problem hiding this comment.
These 3 added lines are not executed by any test. Details
| const addressPortSourceElem = source => (<> | ||
| <DescriptionListGroup> | ||
| <DescriptionListTerm> | ||
| {_("Address")} | ||
| </DescriptionListTerm> | ||
| <DescriptionListDescription id={`${id}-network-${networkId}-address`}> | ||
| {source.address} | ||
| </DescriptionListDescription> | ||
| </DescriptionListGroup> | ||
| <DescriptionListGroup> | ||
| <DescriptionListTerm> | ||
| {_("Port")} | ||
| </DescriptionListTerm> | ||
| <DescriptionListDescription id={`${id}-network-${networkId}-port`}> | ||
| {source.port} | ||
| </DescriptionListDescription> | ||
| </DescriptionListGroup> |
There was a problem hiding this comment.
These 17 added lines are not executed by any test. Details
| {ips.inet6 && <DescriptionListGroup> | ||
| <DescriptionListTerm> | ||
| {_("inet6")} | ||
| </DescriptionListTerm> | ||
| <DescriptionListDescription id={`${id}-network-${networkId}-ipv6-address`}> | ||
| {ips.inet6} | ||
| </DescriptionListDescription> | ||
| </DescriptionListGroup>} |
There was a problem hiding this comment.
These 8 added lines are not executed by any test. Details
|
All green, apart from one unrelated flake |
Network interfaces that are attached to VMs have a TAP device. Tap devices exist to facilitate virtual private networks, network tunnels...
Every virtual network interface is assigned to a TAP device, since tap device is a representation of a virtual network device on lower layers:
If you want to troubleshoot the virtual network device manually, capture its packets, etc. on those lower layers, you need to know the interface name, so we should show it in the UI:
BEFORE
AFTER
Fixes #1047
Show virtual interface's TAP device
Network interfaces attached to VMs have a TAP device assigned, which represents the device at lower layers. Troubleshooting the virtual network device may require knowledge of the associated TAP device.