Crc: Add functionality to communicate from WSL(2) to the CRC VM on Windows

[gbraad]

Although it is early day, WSL2 uses Hyper-V and provides a nice experience when it comes to coding (like remote-WSL from VSCode). Although for WSL2 there is no direct way to communicate from the WSL Virtual Switch to the Default Switch. A possibility would be to add the WSL switch tothe CRC VM once the environment is enabled, and configure accordingly so oc from WSL can communicate with the CRC VM.

Note: this behaviour is different from WSL(v1) where the Windows networking stack is shared between Windows and the Linux susbsystem

[nevermosby]

Hi there, currently I am trying the provision based on wsl2 ubuntu box(using the crc binary of linux version). When I run crc setup inside wsl2 box, it shows some error messages:

david@XXXX:/mnt/c/WINDOWS/system32$ crc setup --log-level debug
INFO Checking if NetworkManager is installed
DEBU Checking if 'nmcli' is available
DEBU 'nmcli' was found in /usr/bin/nmcli
INFO Checking if NetworkManager service is running
DEBU Checking if NetworkManager.service is running
DEBU exit status 1 : System has not been booted with systemd as init system (PID 1). Can't operate.
FATA NetworkManager is required. Please make sure it is installed and running manually

I have done apt install network-manager and started the service manually to make sure it is running. It turns out that in the source code:

// https://github.com/code-ready/crc/blob/master/pkg/crc/preflight/preflight_checks_linux.go#L458
......
path, err := exec.LookPath("systemctl")
...
stdOut, stdErr, err := crcos.RunWithDefaultLocale(path, "is-active", "NetworkManager")
...

Currently the code is using the command systemctl is-active NetworkManager, which is not working now in WSL2 box, it should be like service network-manager status and check the result for "running".

Is it worthy of making a PR to cover the provision for wsl2 box? If so, I am glad to do it.
Looking forward to ur idea.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[gbraad]

The issue here talks about communication between WSL(2) and CRC-VM, like using oc, but actually targeting the underlying Hyper-V to host the CRC-vm.

@nevermosby Note that the setup you tried would never be supported as that involves nested-virtualization in which the environment runs hyper-v -> kvm -> crc-vm instead of hyper-v -> crc-vm or kvm -> crc-vm. Also note that WSL2 is a non-standard configuration that uses their own init system in-place of the distros (and modified kernel). This causes issues when something like systemd is expected. We might come back to this in the future.

[doublefx]

Hi,

Where are we with this issue, now WSL 2 has been officially released?

Without this issue fixed I cannot use Quarkus to send s2i native builds to openshift because the quarkus-openshift extension uses Dekorate which uses OC under the wood.

[mageru]

I found a work around for this issue here -> https://github.com/microsoft/WSL/issues/4288#issuecomment-652259640
Basically you need to retrieve the switch IDs of the virtual switches for CRC and WSL and then enable forwarding support.
Open PowerShell (run as admin)

Retrieve IDs

Get-NetIPInterface | select ifIndex,InterfaceAlias,AddressFamily,ConnectionState,Forwarding | Sort-Object -Property IfIndex | Format-Table

Enabling forwarding for WSL - change MYvEthernetWSLID to the id number of your WSL switch from the previous command

Set-NetIPInterface -ifindex MYvEthernetWSLID -Forwarding Enabled

Enable forwading for CRC - change MYvEthernetSWITCHID to the id number of your WSL switch from the previous command

Set-NetIPInterface -ifindex MYvEthernetSWITCHID -Forwarding Enabled

Immediately after running this I was able to run oc commands in WSL2 without issue.

[zcahana]

The above workaround worked for me - thanks @mageru!

My own poor-man's workaround:
Run oc proxy on the Windows host, bound to the WSL bridge, and access it via the bridge IP from within WSL.
This is rather more involved than @mageru's workaround, but doesn't require tampering with Windows networking:

Here's the details for anyone interested:

On the Windows host:

Retrieve WSL bridge IP address:

netsh interface ip show addresses "vEthernet (WSL)"

Login to the CRC cluster:

oc login -u kubeadmin -p <token> https://api.crc.testing:6443

Start oc proxy/kubectl proxy (accept firewall prompt):

oc proxy --port=8001 --api-prefix='/' --address=<WSL bridge IP> --accept-hosts=".*"

From within WSL:

Retrieve WSL bridge IP address:

WSL_BRIDGE_IP=$(grep nameserver /etc/resolv.conf | sed 's/nameserver //')

Configure an oc/kubectl context to access the CRC cluster:

oc config set clusters.crc.server $WSL_BRIDGE_IP:8001
oc config set contexts.crc.cluster crc
oc config use-context crc

And you're good to go.

Note: Hyper-V bridge IPs seem to change with each system restart, so automate this by putting the corresponding commands in a Windows startup script and in your ~/.profile in WSL.