QEMU commandline should use Instance.SSHAddress insead of hardcoded loopback

[arixmkii]

Description

Currently QEMU always forwards SSH to 127.0.0.1

lima/pkg/qemu/qemu.go

Line 719 in 2c84e0c

args = append(args, "-netdev", fmt.Sprintf("user,id=net0,net=%s,dhcpstart=%s,hostfwd=tcp:127.0.0.1:%d-:22",

This doesn't play well with some WSL2 integration scenarios. It should match the instance address instead, then this address defining logic would reside in from the single source.

I plan to submit a fix for this.

[afbjorklund]

Wouldn't that be from 127.0.0.1? As in from SSHLocalPort on the host, to port 22 in the guest?

[arixmkii]

This is needed for supporting NAT mode userland + QEMU on Windows. QEMU has to listen on internal IP, where WSL apps can connect #909 (comment)

It is impossible (w/o additional tooling) to access Windows loopback from WSL2 linux, when in NAT mode.

[afbjorklund]

So you want to connect to the Lima instance in WSL, from another WSL container ("distro", whatever) ?

[arixmkii]

So you want to connect to the Lima instance in WSL, from another WSL container ("distro", whatever) ?

To Lima instance in QEMU via ssh and friends running inside WSL container.

Yes, because tooling in cygwin/msys2 (specifically ssh mux is impossible) doesn't work for all features. I'm doing remote shells to tiny Alpine WSL2 for needed utilities. I will write the detailed summary to explain how it works. I hope to do it as soon as I finish with my first iteration of patches.

[arixmkii]

So you gave up on Windows, and prefer using Linux? Well that is understandable, I suppose :-)

I definitely gave up on using Windows SSH tooling for advanced scenarios. They are good for what they were ported for, but not beyond that set of scenarios. Using full featured Linux tooling was a huge relief :-)

EDIT: Also, the newly added features of making a distro in tgz format and installing it by double click or simple command line made a lot of difference here. It is really convenient.

[arixmkii]

So you gave up on Windows, and prefer using Linux? Well that is understandable, I suppose :-)

@afbjorklund I have one fresh example of why Windows tooling can't be trusted #2775 (comment)