How to "routing between them" when using MULTIPASS_SERVER_ADDRESS

[lars18th]

Description of documentation issue or suggestion

This is related to the page: How to use Multipass remotely
https://multipass.run/docs/how-to-use-multipass-remotely

The problem is the section:

Some commands (shell, exec, mount) currently rely on direct networking
between the client and the instance. For these to work, you’ll need to
ensure routing between them is possible.

I want to use multipass cli tool with MULTIPASS_SERVER_ADDRESS. In fact, it's now working. But shell and transfer commands doesn't work (and they doesn't describe any error).

Therefore I need help about "how to ensure routing between the host running multipass in remote and the vm".
Nothing describes this. What we need?

Proposal to fix issue or enact suggestion

The documentation is incomplete.

Additional context

I am testing in different scenarios, and commands like shell never work.

[lars18th]

Perhaps a simple upgrade in the documentation will be sufficient:

Some commands (shell, exec, mount) currently rely on direct networking
between the client and the instance. For these to work, you’ll need to
ensure **network** routing between them is possible. ** Check the ip
address of the instance with command `multipass list` or `multipass list` **.

[georgeliao]

Hi @lars18th
Thanks for reporting. Our documentation needs to be adjusted a bit to reflect on this. The current multipass support for remote daemon is still very limited.

[ricab]

Agreed. We're aware of the limitations you are facing @lars18th. This is essentially still on the status of "hack" and we need to rethink how we present it in the documentation to avoid giving a different impression. Supporting remote daemon/client properly would require many changes and is not in our immediate future.

[lars18th]

Hi @ricab ,

I hope you want to add minimal remote support. For example, adding the option to configure a proxy (#3751). I understand this is not a priority, but the current functionality is sufficient in several use cases. The only issue right now is how to route the ssh connection to the instances.

[ricab]

In the future, eventually, this is something we will probably want to look into but, in all honesty, we have a large number of things with more priority requiring our attention on the local desktop case. We prefer to have a consolidated foundation before we move on to more fancy stuff like this.