Docker snap interferes with lxd snap

snap
1

After connecting lxd to a custom bridge, installing docker breaks it such that lxc containers can no longer obtain IP addresses.

Repro case:

  1. Create an ubuntu server 19.10 VM

  2. Execute the following as root in the VM:

    cat </etc/netplan/01-br0.yaml
    network:
    version: 2
    renderer: networkd
    ethernets:
    ens3:
    dhcp4: false
    dhcp6: false
    bridges:
    br0:
    interfaces: [ens3]
    dhcp4: true
    parameters:
    stp: false
    forward-delay: 0
    EOF
    rm /etc/netplan/50-cloud-init.yaml
    netplan apply

  3. Switch to the normal user and run lxd init. Use storage pool type “dir”. Say no to creating a bridge, and yes to use an existing bridge. Use bridge “br0”. Choose defaults for everything else.

  4. Run lxc launch ubuntu:18.04 test

  5. Run lxc list to see that container “test” has an ipv4 address:

    ±-----±--------±----------------------±-----±-----------±----------+
    | NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS |
    ±-----±--------±----------------------±-----±-----------±----------+
    | test | RUNNING | 192.168.122.46 (eth0) | | PERSISTENT | 0 |
    ±-----±--------±----------------------±-----±-----------±----------+

  6. Run sudo snap install docker

  7. Reboot the VM

  8. Log in as normal user again and type lxc list to see that the container no longer has an ipv4 address:

    ±-----±--------±-----±-----±-----------±----------+
    | NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS |
    ±-----±--------±-----±-----±-----------±----------+
    | test | RUNNING | | | PERSISTENT | 0 |
    ±-----±--------±-----±-----±-----------±----------+

From this point forward, no lxc containers will ever get an IP address.

If you do all of these steps without installing docker (step 6), it works perfectly.

2

@tianon can you take a look at this?

3

Sorry for the delay here – I wonder if this is a problem that’s unique to the snap, or if this is something that would affect any mixed Docker+LXC system?

Docker does a lot of hand-holding for making sure networking is “easy” and it does have a tendency to trample the host networking stack (by design), so while this doesn’t necessarily surprise me, it does strike me as odd (since Docker shouldn’t be touching that br0, and should also automatically avoid the IP range it is using by default).