Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for bridged networking #118

Open
gwatts opened this issue Feb 9, 2018 · 16 comments
Open

Support for bridged networking #118

gwatts opened this issue Feb 9, 2018 · 16 comments
Labels
Projects

Comments

@gwatts
Copy link

@gwatts gwatts commented Feb 9, 2018

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?

@Saviq Saviq added the enhancement label Feb 9, 2018
@carmine

This comment has been minimized.

Copy link

@carmine carmine commented Jun 25, 2018

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

This comment has been minimized.

Copy link
Collaborator

@Saviq Saviq commented Jun 25, 2018

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

This comment has been minimized.

Copy link

@carmine carmine commented Jun 25, 2018

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

This comment has been minimized.

Copy link
Collaborator

@Saviq Saviq commented Jun 25, 2018

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

This comment has been minimized.

Copy link

@popey popey commented Jul 3, 2018

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

This comment has been minimized.

Copy link

@dhenrich dhenrich commented Jul 3, 2018

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

@hyzhak

This comment has been minimized.

Copy link

@hyzhak hyzhak commented Oct 26, 2018

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.

Saviq added a commit that referenced this issue Feb 11, 2019
Merge #118
118: Bump copyright to 2019 r=Saviq a=gerboland

Co-authored-by: Gerry Boland <gerry.boland@canonical.com>
@Saviq Saviq added this to To do in 19.10 cycle via automation Feb 21, 2019
@kbknapp

This comment has been minimized.

Copy link

@kbknapp kbknapp commented Sep 19, 2019

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

This comment has been minimized.

Copy link

@Gnommer Gnommer commented Sep 20, 2019

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

This comment has been minimized.

Copy link
Collaborator

@Saviq Saviq commented Sep 30, 2019

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

This comment has been minimized.

Copy link

@v1k0d3n v1k0d3n commented Dec 11, 2019

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

@Saviq

This comment has been minimized.

Copy link
Collaborator

@Saviq Saviq commented Dec 12, 2019

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

@v1k0d3n

This comment has been minimized.

Copy link

@v1k0d3n v1k0d3n commented Dec 19, 2019

@Saviq that's unfortunate. :(

boo

@richiethom

This comment has been minimized.

Copy link

@richiethom richiethom commented Dec 23, 2019

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

This comment has been minimized.

Copy link

@ibehren1 ibehren1 commented Dec 26, 2019

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

This comment has been minimized.

Copy link
Collaborator

@Saviq Saviq commented Jan 7, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
19.10 cycle
  
To do
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
You can’t perform that action at this time.