Networks unimplemented on the qemu driver on Linux

phial3 commented 2 years ago

➜ ~ multipass launch --cpus 2 --mem 1G --name meta01 --network bridged 21.10 launch failed: The bridging feature is not implemented on this backend. ➜ ~ multipass networks networks failed: The networks feature is not implemented on this backend. ➜ ~ multipass launch --cpus 2 --mem 1G --name meta01 --network WLAN 21.10 launch failed: The bridging feature is not implemented on this backend.

multipass create network is not used now,

townsend2010 commented 2 years ago

Hi @phial3,

It's not clear from your bug report which host platform you are running Multipass on and if you changed the default driver to something other than the default. --network is not supported on all combinations of hosts and hypervisor drivers yet.

Could you please provide the following?

Host platform
Output of sudo multipass get local.driver

Thanks!

holta commented 2 years ago

FYI I have the same issue! Or close:

Indeed, all multipass launch --network XXXX commands (and the multipass networks command) fail with almost the same error:

networks failed: The networks feature is not implemented on this backend.

Could you please provide the following?

Host platform

Ubuntu 22.04 on x86_64.

I tried all 3 versions of multipass below — and the error is the same in each case:

latest/stable: 1.8.0 2022-04-26 (6904)
latest/beta: 1.9.0 2022-04-26 (6920)
latest/edge: 1.10.0-dev.887+g9c51de65 2022-04-22 (6914)

Output of sudo multipass get local.driver

qemu

(Any Suggestions?)

holta commented 2 years ago

Above report (from 10 min ago) cleaned up!

Apologies for the earlier typos.

holta commented 2 years ago

Possibly multipass launch --network XXXX and multipass networks still require LXD on Ubuntu?

Unfortunate if this is still true — but ok, that would explain it — according to https://multipass.run/docs/networks-command which says:

At this time, networks can only find interfaces in the following scenarios:

on Linux, with LXD...

holta commented 2 years ago

These 3 lines work decently — to create Multipass VM's with their own public/routable/reachable IP addresses:

snap install lxd
multipass set local.driver=lxd
multipass launch --network enp1s0

The catch is that Multipass clobbers the host's Internet gateway interface (e.g. enp1s0 on Ubuntu Desktop 22.04 host machine above) forcing this host to a new IP address (interface br-enp1s0). Unfortunately Multipass quite understates the damage/blowback when it (tries!) to alert you as follows;

Multipass needs to create a bridge to connect to enp1s0. This will temporarily disrupt connectivity on that interface.

Do you want to continue (yes/no)?

IN SHORT: The connectivity disruption (for those trying to reach their Multipass host machine from the outside) is more than temporary. Reason: it permanently loses its static IP address — not elegant if that IP is hard-coded in your home router based on the machine's hardware MAC address :/

But on the bright side this 3-line formula does at least provide a public IP address for Multipass VM's.

Saviq commented 2 years ago

@holta that's just how bridging works on Linux… the bridge is what gets the IP address, and the bridge has a different MAC. Having a hardcoded MAC/static IP is a special case - we couldn't cater for everything.

You can create the bridge yourself in whatever way you wish, too - and Multipass will use that.

holta commented 2 years ago

You can create the bridge yourself in whatever way you wish, too - and Multipass will use that.

Good the know!

A host's existing gateway interface and its MAC address can certainly be preserved — i.e. made to work with an added bridge.

At the same time I do understand Multipass development likely has many other urgent priorities — e.g. perhaps renaming/copying VM's, LXD 5.0 integration/polish and/or whatever usability improvements keep the product moving forward ✅

holta commented 2 years ago

Just FYI running multipass set local.driver=qemu immediately creates 2 bridges (mpbr0 and mpqemubr0) below — and one of these (mpbr0) disappears on rebooting.

(This seems odd — is this 2nd bridge just a transient/harmless artifact?)

# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group defaul                                                                                        t qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP gr                                                                                        oup default qlen 1000
    link/ether 84:47:09:0a:38:c8 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.126/24 brd 192.168.0.255 scope global noprefixroute enp1s0
       valid_lft forever preferred_lft forever
    inet6 fe80::d061:4f90:6306:95d9/64 scope link noprefixroute
       valid_lft forever preferred_lft forever
3: wlp3s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN                                                                                         group default qlen 1000
    link/ether 2c:8d:b1:69:a9:d3 brd ff:ff:ff:ff:ff:ff
4: mpqemubr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state D                                                                                        OWN group default qlen 1000
    link/ether 52:54:00:68:f9:cb brd ff:ff:ff:ff:ff:ff
    inet 10.52.33.1/24 brd 10.52.33.255 scope global mpqemubr0
       valid_lft forever preferred_lft forever

# multipass get local.driver
qemu

# multipass set local.driver=lxd

# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 84:47:09:0a:38:c8 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.126/24 brd 192.168.0.255 scope global noprefixroute enp1s0
       valid_lft forever preferred_lft forever
    inet6 fe80::d061:4f90:6306:95d9/64 scope link noprefixroute
       valid_lft forever preferred_lft forever
3: wlp3s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
    link/ether 2c:8d:b1:69:a9:d3 brd ff:ff:ff:ff:ff:ff

# multipass get local.driver
lxd

# multipass set local.driver=qemu

# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 84:47:09:0a:38:c8 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.126/24 brd 192.168.0.255 scope global noprefixroute enp1s0
       valid_lft forever preferred_lft forever
    inet6 fe80::d061:4f90:6306:95d9/64 scope link noprefixroute
       valid_lft forever preferred_lft forever
3: wlp3s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
    link/ether 2c:8d:b1:69:a9:d3 brd ff:ff:ff:ff:ff:ff
5: mpbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
    link/ether 00:16:3e:4f:bc:d3 brd ff:ff:ff:ff:ff:ff
    inet 10.144.22.1/24 scope global mpbr0
       valid_lft forever preferred_lft forever
    inet6 fd42:b559:b225:598b::1/64 scope global
       valid_lft forever preferred_lft forever
6: mpqemubr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
    link/ether 52:54:00:ce:c4:3a brd ff:ff:ff:ff:ff:ff
    inet 10.52.33.1/24 brd 10.52.33.255 scope global mpqemubr0
       valid_lft forever preferred_lft forever

# snap info multipass
[...]
snap-id:      mA11087v6dR3IEcQLgICQVjuvhUUBUKM
tracking:     latest/edge
refresh-date: today at 18:02 EDT
channels:
  latest/stable:    1.8.0                    2022-04-26 (6904) 134MB -
  latest/candidate: 1.8.0                    2022-04-21 (6904) 134MB -
  latest/beta:      1.9.0                    2022-04-26 (6920) 134MB -
  latest/edge:      1.10.0-dev.887+g9c51de65 2022-04-22 (6914) 134MB -
installed:          1.10.0-dev.887+g9c51de65            (6914) 134MB -

# snap info lxd
[...]
snap-id:      J60k4JY0HppjwOjW8dZdYc8obXKxujRu
tracking:     latest/stable
refresh-date: today at 06:35 EDT
channels:
  latest/stable:    5.0.0-b0287c1 2022-04-20 (22923) 83MB -
[...]

holta commented 2 years ago

CLARIFS:

Bridge mpbr0 in fact arises from running multipass set local.driver=lxd but I didn't realize that at first — as this bridge appears about 5-or-more seconds later.

(Above command also instantly removes bridge mpqemubr0)
Subsequently running multipass set local.driver=qemu instantly adds bridge mpqemubr0 which is what leads to 2 simultaneous bridges.

(Above command does not actively remove bridge mpbr0 — this 2nd bridge does however disappear if you reboot.)

Saviq commented 2 years ago

mpqemubr0 is the NAT bridge for the qemu driver. The mpbr0 one is managed by LXD, when using the lxd driver. All that's by design.

holta commented 2 years ago

@jvonau asked how ip r looks so I'm posting that output, for him and anybody's that's curious:

# multipass get local.driver
qemu

# ip r
default via 192.168.0.1 dev enp1s0 proto dhcp metric 100
10.52.33.0/24 dev mpqemubr0 proto kernel scope link src 10.52.33.1 linkdown
10.144.22.0/24 dev mpbr0 proto kernel scope link src 10.144.22.1 linkdown
169.254.0.0/16 dev mpbr0 scope link metric 1000 linkdown
192.168.0.0/24 dev enp1s0 proto kernel scope link src 192.168.0.126 metric 100

# multipass get local.driver
lxd

# ip r
default via 192.168.0.1 dev enp1s0 proto dhcp metric 100
10.144.22.0/24 dev mpbr0 proto kernel scope link src 10.144.22.1 linkdown
169.254.0.0/16 dev mpbr0 scope link metric 1000 linkdown
192.168.0.0/24 dev enp1s0 proto kernel scope link src 192.168.0.126 metric 100

Then after adding a bridged VM (multipass launch --network enp1s0) the above changes a bit — (1) the PC's IP address is forced from 192.168.0.126 to 192.168.0.205, (2) metric 100 becomes metric 425 in both places, and (3) 169.254.0.0/16 no longer shows linkdown as you can see:

# ip r
default via 192.168.0.1 dev br-enp1s0 proto dhcp metric 425
10.144.22.0/24 dev mpbr0 proto kernel scope link src 10.144.22.1
169.254.0.0/16 dev mpbr0 scope link metric 1000
192.168.0.0/24 dev br-enp1s0 proto kernel scope link src 192.168.0.205 metric 425

Finally, here is ip a output when a bridged VM is in place:

# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br-enp1s0 state UP group default qlen 1000
    link/ether 84:47:09:0a:38:c8 brd ff:ff:ff:ff:ff:ff
3: wlp3s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
    link/ether 2c:8d:b1:69:a9:d3 brd ff:ff:ff:ff:ff:ff
5: mpbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 00:16:3e:4f:bc:d3 brd ff:ff:ff:ff:ff:ff
    inet 10.144.22.1/24 scope global mpbr0
       valid_lft forever preferred_lft forever
    inet6 fd42:b559:b225:598b::1/64 scope global
       valid_lft forever preferred_lft forever
    inet6 fe80::216:3eff:fe4f:bcd3/64 scope link
       valid_lft forever preferred_lft forever
8: br-enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 0e:44:34:87:22:9c brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.205/24 brd 192.168.0.255 scope global dynamic noprefixroute br-enp1s0
       valid_lft 6628sec preferred_lft 6628sec
    inet6 fe80::626b:a414:e87f:1e56/64 scope link noprefixroute
       valid_lft forever preferred_lft forever
9: tapc471c803: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master mpbr0 state UP group default qlen 1000
    link/ether ee:a5:ec:32:e5:c2 brd ff:ff:ff:ff:ff:ff
10: tapdba58baf: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br-enp1s0 state UP group default qlen 1000
    link/ether c2:81:54:bb:32:36 brd ff:ff:ff:ff:ff:ff

(As you can see enp1s0 has lost its longstanding 192.168.0.126 IP address, that has always been set by the router — prior to today anyway.)

FWIW kernel is 5.15.0-27-generic #28-Ubuntu SMP Thu Apr 14 04:55:28 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux (running on Ubuntu Desktop 22.04).

holta commented 2 years ago

It took a long time, but I was finally able to recover from the (accidental, but very real) damage caused by Multipass to my PC's networking configuration.

Wiping the OS (not fun) when a program wipes out essential networking on the computer that you depend on every day...is the sad reality we need to avoid.

So others can hopefully recover when this happens to them too — here's the command that worked for me to restore the PC's networking:

nmcli connection delete br-enp1s0

holta commented 2 years ago

that's just how bridging works on Linux… the bridge is what gets the IP address, and the bridge has a different MAC.

Point of Clarification:

VirtualBox does not change the Linux host's gateway MAC address and IP address — when creating bridged VM's that anybody in the house can access at IP's like 192.168.0.*

Suggestion:

It would absolutely incredible if Multipass similarly/seamlessly allowed VM's to be visible on a home/office network in coming years, respecting the host PC's networking configuration. Obviously Multipass is not trying to become VirtualBox (nor should it!) And regrettably this might not be possibly in 2022. (But if Multipass should find a way to make this possible in coming years, this will truly make a Night and Day difference!)

Summary:

Multipass can damage your (Ubuntu) host PC's networking configuration — unlike VirtualBox which respects your PC's networking configuration. Obviously Multipass is NOT causing damage on purpose! But indeed that's the result, from a pragmatic/user perspective (other devices in the home/office can no longer reach the PC). So the warning proposed below is a great 1st step: :smiley:

2543

Saviq commented 2 years ago

VirtualBox isn't using Linux Bridging, it has a whole networking stack implemented in software. Which is nice for portability, but is bad in many other aspects (and why you don't actually get a routable IP with the default VirtualBox network).

I would ask that you not use the word "damage". Other devices can certainly reach your PC, but on a different IP address. As discussed, we won't be able to cater for every networking config out there - we do, however, cater to the most common one, where dynamic IPs and name resolution are the most common approach.

holta commented 2 years ago

VirtualBox isn't using Linux Bridging, it has a whole networking stack implemented in software. Which is nice for portability, but is bad in many other aspects (and why you don't actually get a routable IP with the default VirtualBox network).

Thanks for explaining.

Certainly multipass launch --bridged announces:

"the network will be disconnected once. Be careful not to panic!"

That's well-intended messaging perhaps, but can be incredibly misleading.

When I and others have to spend countless hours in damage control, to recover a critical PC (Multipass would not unroll its actions) we should try not to paper over the consequences.

Users have a right to know in advance — in very honest language:

(1) Multipass can permanently change their computer's IP address.

(2) HOW to reverse Multipass's actions to regain control over their effectively no longer operational system (e.g. I spent hours recovering my Ubuntu 22.04 PC, it being unable to access the Internet at all several times, until figuring out how to reverse Multipass's effectively permanent alterations to my PC).

Hence #2543: If a cough syrup does not include on its label a warning that it may cause dangerous side effects if taken in combination with another commonly taken drug such as aspirin... arguing over the dictionary definition of the word "damage" is not helpful to anybody... when the victims just want to live their lives and recover.

canonical / multipass

Networks unimplemented on the qemu driver on Linux #2537

2543