How to use Multipass remotely

This document will demonstrate how to use Multipass remotely. This can be useful, for example, if you want to run your VMs on a more powerful machine.


Expose Multipass to your network

To expose Multipass to your network, pass --address when starting the daemon:

$ multipassd --help
# ...
  --address <server_name:port>                      specifies which address to
                                                    use for the multipassd
                                                    service; a socket can be
                                                    specified using

The client accepts the MULTIPASS_SERVER_ADDRESS environment variable that overrides the default:
$ MULTIPASS_SERVER_ADDRESS=<hostname>:51001 multipass find
Image                       Aliases           Version          Description
21.10                       impish            20220118         Ubuntu 21.10


- Because mounts are executed as privileged users, it is recommended to use Multipass 1.9.0, to use client authentication, so you need to explicitly allow clients access with a shared passphrase.
Alternatively, you can multipass set local.privileged-mounts=false to disable the mounts feature altogether.
- Some commands (shell, exec, mount) currently rely on direct networking between the client and the instance, for those to work you’ll need to ensure routing between them is possible.

Change the daemon settings


You can systemctl edit snap.multipass.multipassd.service and place content along these lines (replace <hostname> with the hostname or the IP you want it to listen on) in:

ExecStart=/usr/bin/snap run multipass.multipassd --address <hostname>:51005

Restart the service then:

$ snap stop multipass
$ snap start multipass


On macOS you’ll need to add it to the service definition (again, replace <hostname>) and reload it:

$ sudo /usr/libexec/PlistBuddy \
  -c "Add :ProgramArguments: string --address" \
  -c "Add :ProgramArguments: string <hostname>:51001" \
$ sudo launchctl unload /Library/LaunchDaemons/com.canonical.multipassd.plist
$ sudo launchctl load /Library/LaunchDaemons/com.canonical.multipassd.plist

NB: reinstallation / upgrade will overwrite those changes


On Windows you’d need to edit/recreate the service definition, and that’s non-trivial (if you do, remember to pass /svc as the first argument to the multipassd.exe binary, and that we currently use the LocalService account)…

As a one-time thing you can use the Start parameters field in the Services panel after stopping the service:

Let us know how this worked for you and what you’d like to see next!


Looks excellent! One small query. If I am running Multipass on a Linux host, is there a guide on exposing the bridged IPs of those vms to the LAN network? (other than routes on the remote machine) If I’m managing my Multipass VMs from a remote host it is likely that I would need to be able to also access the services on that system remotely (a website etc…).

Hope that makes sense! I tried bridging Multipass to my LAN on a linux machine before (using LXD driver) and it just wouldn’t work. I had to use Windows in the end as it bridged correctly, but would prefer to use Linux obviously. But I could be missing something. Any guide or pointers appreciated!


@rootisgod if you’re after exposing the instances on your network, --network is the way to go. Would you please file an issue with some details?

As for ensuring connectivity between your host and remote instances, that would require setting up routes appropriately on your workstation, which would roughly be ip route add <network> via <multipass host IP>. Assuming that you’re on Linux:

$ MULTIPASS_SERVER_ADDRESS= multipass launch
Launched: passionate-macaw

$ multipass shell passionate-macaw              
shell failed: ssh connection failed: 'Timeout connecting to'

$ sudo ip route add via

$ multipass exec passionate-macaw -- uname -a   
Linux passionate-macaw 5.4.0-96-generic #109-Ubuntu SMP Wed Jan 12 18:07:25 UTC 2022 aarch64 aarch64 aarch64 GNU/Linux

On any other host adding the appropriate route should equally work :).

Thanks very much for the reply. Let me test my exact setup again and file an issue if I can’t get a bridge working. Thanks for the route commands, that will definitely go a long way, ta.