Support for bridged networking

[gwatts]

I often want to run services in a VM that are reachable from the local network. The easiest way for me to do that is to use a bridged network interface, so that the VM appears to be directly on the LAN.

Are there any plans to add that kind of network interface?

[carmine]

I assume bridged networking is the same as host networking - ie the VM uses the same IP as the host? If so, I'd like to vote for this feature too.

It'll facilitate scenarios where an Application in the VM, accessed through a browser, does a redirection. I've come across this in a kubernetes setup .. port mapping / nat. Whereas this isn't specifically a multipass issue, presumably host networking would alleviate the pain point (the pain of finding another workaround).

[Saviq]

Not the same IP, but the same subnet, getting IPs from the same DHCP server. This could partially be achieved by forwarding ports on the host IP to ports in the instance - in this case you actually gain control over what's exposed vs. exposing all services from the instance.

[carmine]

The port forwarding works for kubernetes .. ie they have a networking concept called NodePort which exposes a port in the range of 30000-33000, or something like that. With that, I can access the embedded jupyterhub. It's when I tell it to spawn something, and the ensuing redirect happens, that I get into trouble. I'll pose an example so that it is easier to see.

[Saviq]

I think with kubernetes we're getting into two levels of indirection - Multipass starts a virtual machine instance and then k8s starts containers inside? Which means there's three networks - host (your non-virtual physical/WiFi network), Multipass's subnet and then inside the VM, one more subnet for k8s. Even when k8s exposes something, it will expose it at most on the VM's IP, which is in a Multipass-private subnet.

This issue is about putting the Multipass instances on your physical network, "next to" your host. K8s would still use an internal network, but the services it would expose would be available to others on your physical network. Something similar can be achieved with port forwarding where services inside the Multipass-private subnet would be exposed on your host's IP, again making them available on your non-virtual network.

[popey]

Adding a +1 for this feature. I frequently spin up servers on VMs to test them, and want to access them from outside without having to do any port forwarding nonsense. Having the VM exposed on the LAN as if it were just another machine is the way I tend to use this.

[dhenrich]

Agreed. It's a common use case for developers and something I'd find really useful.

[hyzhak]

My case: I was trying to setup kubeflow on microk8s, which inside of multipass on my small local DL server. Here is official instruction, but because of this issue it didn't work well. I couldn't get access to the services of kubeflow (Jupyter, k8s dashboard, tf dashboard and etc). So it would great if multipass would give access from local network to any web app inside of multipass.

[kbknapp]

I'll add my use case to this.

At work we currently use LXD to spin up several containers on a separate bridge network creating a island of containers for a large testing infrastructure. Each container has two interfaces, one connected to the bridge with a private IP, and the other connected to the standard LXD lxdbr0.

We do this several times, so end up with several islands of containers. We then use normal brctl to separate these bridges with VLAN tagging to keep these islands from talking directly over the network.

The end state (for two islands of 3 containres each):

• "island 1" containers can talk to each other, and to the host
• "island 2" containers can talk to each other, and to the host
• The islands can't talk to each other except through the host

This allows the host to simulate "the internet", and the islands to simulate private networks.

This all works great, except some of the tests are requiring full blown VMs instead of containers (since they need to mess with the kernel and such).

multipass would be a great solution to this problem so we could still take advantage of all the testing infrastructure automation. However, if we can't add additional networking interfaces and network bridges to multipass VMs (a la lxc network create foobr0 && lxc config device add island-1-container eth1 nic nictype=bridged parent=foobr0 name=eth1) it's not viable yet.
`

[gnommer]

I have a case where I have to develop dockerized apps and I don't have access to windows 10 pro for (docker for windows). multipass seemed like a viable vm solution unlike other methods to make vms cause its light and fast. though on the windows build 1903 it seems the ipv4 address is not detected. and its shown as N/A. I am using virtualbox for the localdriver can any help me out on this ?

[Saviq]

Hi @gnommer, yes VirtualBox's networking does not mimic a normal network segment, it all happens in a software router they implement. Which is why the IP is reported as N/A, because it's meaningless outside of the instance anyway.

Bridging is an option there, and we'll be looking at implementing it soon.

[v1k0d3n]

any updates @Saviq? I'm following, but not as closely as I'd like.

[Saviq]

Hey @v1k0d3n, I'm afraid it doesn't look like we'll get to this in the immediate future :/

[v1k0d3n]

@Saviq that's unfortunate. :(

[richiethom]

It'd be really good to include this limitation in the documentation, perhaps also showing it as a warning near the instructions for switching from HyperV to VirtualBox?

[ibehren1]

Is the issue with bridged networking because the snap has no interfaces defined?

I have set the driver to libvirt and multipass spins up the instance find on the libvirt side, the instance gets an IP from my network dhcp server and is good but multipass times out and never gets the "metadata". As a result it only has the ability to stop/start the VM but takes forever to do so b/c it cannot connect to it.

I found the ssh key buried in the /var/snap/... dir and can get on the instance. All good there. Seems like it should be simple enough to allow multipass to talk to outside network.

Without bridged networking, the use case for multipass is pretty limited. If bridged networking can be enabled, it is a fabulous interface to libvirt which adds a ton of use cases. Love the simplicity of spinning of instances and specifying base cpu/mem/disk and getting a working base OS in seconds.

[Saviq]

The issue with bridged networking is that Multipass (nor the hypervisor) are in control of the network any more. So long as we rely on networking to the instance, we need to know the IP of the instance. We're taking that from the hypervisors' DHCP servers today - when bridging, we don't have that source.

We could scrape the console output, but that proves unreliable.

In the future we want to switch to interacting with the instance over vsock (or platform equivalent), which would make this feature quite a bit simpler.

[a1git]

I am on ubuntu 20

multipass 1.5.0
multipassd 1.5.0

multipass launch --network
Unknown option 'network'.

[a1git]

multipass list-networks => Error: Unknown Command 'list-networks'

[Saviq]

@a1git only VirtualBox and Hyper-V are implemented so far. We're working on the other platforms now.

[takogata]

@ricab Is the preliminary version (for Windows) still available somewhere? I get a 403 Access denied using the download links.

[Saviq]

@ricab Is the preliminary version (for Windows) still available somewhere? I get a 403 Access denied using the download links.

Now available on the 1.6.0 RC tag:

https://github.com/canonical/multipass/releases/tag/v1.6.0-rc

[yorch]

@Saviq is there any Github issue tracking the progress? I would love to use bridged networking on my Ubuntu box running multipass. Thanks!

[SlyCooperking]

@Saviq is there any Github issue tracking the progress? I would love to use bridged networking on my Ubuntu box running multipass. Thanks!

I think they had gotten it working for the most part. I can now host servers with my multi pass instances and ping them from a client.

[yorch]

@SlyCooperking how did you configure it them? I'm getting: networks failed: The networks feature is not implemented on this backend. when trying to run multipass networks

[SlyCooperking]

@yorch Perhaps someone else might be able to jump in, I don't remember the error I received before making changes, but Perhaps similar changes will help you.

You will need to create a vEthernet (External Switch) appear in Control Panel\Network and Internet\Network Connections

You may need to create a network bridge between your wifi adapter connection and your vEthernet (External Switch) both should be in the above control panel location.

This May get you started on creating the virtual switch and bridge, which you will need to do within Hyper-V https://docs.microsoft.com/en-us/windows-server/virtualization/hyper-v/get-started/create-a-virtual-switch-for-hyper-v-virtual-machines

AS for the network bridge This may be of help. https://www.windowscentral.com/how-set-and-manage-network-bridge-connection-windows-10

Hope this helps.

[yorch]

@SlyCooperking thanks, unfortunately, I'm using Ubuntu as my host.

[Saviq]

@SlyCooperking thanks, unfortunately, I'm using Ubuntu as my host.

Hi @yorch, the feature is available on Linux, too, using the LXD backend. Use sudo multipass set local.driver=lxd to switch to it, then networks will work. You will need to create the bridge yourself while we're working on making this automatic where possible.

[dennistanaka]

Just passing by to say thank you, this feature is great. I even had stopped trying multipass before 1.6 due to the lack of bridge support, but I tested 1.6.1 on Windows 10 + Hyper-V and could access the VM with no problems from another machine in the network. I usually don't use this Windows desktop for development and I wanted to put its resources for use while on and not playing games, and it's been great to use Multipass to run VMs on it. Thanks!

[ikiK-CRO]

Does multipass-1.6.1+mac-Darwin.pkg (that is RC relase?) has support for bridged network without suing VirtualBox? I cant use VirtualBox on some machines as there is conflict with some FUSE (sshfs) features that I use, they can not run side by side, installing VirtualBox is not an option for me. If not are there plans for some native OSX solution?

[rgigger]

Working for me on MacOS Big Sur!

Was this with virtual box?

[Saviq]

@ikiK-CRO @rgigger on macOS only VirtualBox is supported now. We'll be working on integrating with the new virtualization API in Big Sur soon. It will fall together with #1857.

We forgot to close this, too.

[underrun]

@Saviq is there an issue tracking bridged networking support for macos with native apis / non-virtualbox separate to the ARM related ticket? if it's all the same work then maybe the title could reflect that? if there's a bridging specific ticket for other hypervisors on macos could you link it here?

[Saviq]

@underrun no separate ticket, it will come along with the new API support. I've changed the title there to "Apple M1 / Virtualization framework support" so that it reflects more what needs to happen. Won't call out bridging specifically, we'd have to list much more that way.

[maximehyh]

Hello,

Would it be possible to have a detailed example on how to set a brdige network with multipass? I am currently running multipass on Windows and I am having trouble exposing my service on the network.

So far I have been trying the following (I am using Hyper-V):

# List of available network interfaces (I wonder if the ones of interest are not missing?)
PS C:\Windows\system32> multipass networks
Name            Type    Description
Default Switch  switch  Virtual Switch with internal networking
WSL             switch  Virtual Switch with internal networking

PS C:\Windows\system32> multipass set local.bridged-network="Default Switch"
PS C:\Windows\system32> multipass launch --bridged
Launched: compatible-chicken
PS C:\Windows\system32> multipass list
Name                    State             IPv4             Image
compatible-chicken      Running           172.20.227.149   Ubuntu 20.04 LTS
                                          172.20.237.96

Making sure I can access the service from the host:

PS C:\Windows\system32> curl http://172.20.227.149:32218/ -UseBasicParsing
StatusCode        : 200
StatusDescription : OK
Content           : Hello, world!
                    Version: 1.0.0
                    Hostname: hello-world-57fbf88c7-xx6p5

RawContent        : HTTP/1.1 200 OK
                    Content-Length: 67
                    Content-Type: text/plain; charset=utf-8
                    Date: Wed, 30 Mar 2022 03:05:01 GMT

                    Hello, world!
                    Version: 1.0.0
                    Hostname: hello-world-57fbf88c7-xx6p5

Forms             :
Headers           : {[Content-Length, 67], [Content-Type, text/plain; charset=utf-8], [Date, Wed, 30 Mar 2022 03:05:01 GMT]}
Images            : {}
InputFields       : {}
Links             : {}
ParsedHtml        :
RawContentLength  : 67

FYI the service is running in microk8s but I do not think this is really relevant as I am already able to access the service from the host.

Thanks

[NobShen]

Using multipass 1.9.2, I'm able to create VM's with ipv4 addr from my local network by bridging to eth0 . However, doing so would remove ipv4 addr from my host PC. Now I can't ssh into the host PC from another PC but I can ssh to the VM fine. Is this a bug?

I'm using Ubuntu 22.04 server on the host PC.

[Saviq]

Hi @NobShen, it doesn't remove it, but indeed it changes it - it's the bridge that gets the IP (and it has a different MAC address), not the physical interface.

[daviewales]

If you've ended up here because you want to connect to multipass from WSL, I don't think you need the bridged networking. You need to enable forwarding on the Windows side. (See comment on WSL issue)

From an admin PowerShell:

Set-NetIPInterface -ifAlias "vEthernet (WSL)" -Forwarding Enabled
Set-NetIPInterface -ifAlias "vEthernet (Default Switch)" -Forwarding Enabled

Now you can connect to multipass from WSL.