notes from Network management with LXD (2.3+)
create a new network with a random IPv4 and IPv6 subnet and NAT enabled:
look at its config with:
$ lxc network create testbr0
$ lxc network show testbr0
to manual configure subnets:
attach to all containers:
$ lxc network create testbr0 ipv6.address=none ipv4.address=10.0.3.1/24 ipv4.nat=true
$ lxc network attach-profile testbr0 default eth0
attach to a single existing container:
convert bridge to an openvswitch bridge (need openvswitch installed first):
$ lxc network attach my-container default eth0
$ lxc network set testbr0 bridge.driver openvswitch
edit the network configuration interactively in your text editor:
$ lxc network edit
LXD manages the DHCP server for you.
a full example:
$ lxc init ubuntu:16.04 c1 $ lxc network attach testbr0 c1 eth0 $ lxc config device set c1 eth0 ipv4.address 10.0.3.123 $ lxc start c1 $ lxc list c1
LXD runs a DNS server on the bridge.
On top of letting you set the DNS domain for the bridge (
dns.domain network property),
it also supports 3 different operating modes (
managedwill have one DNS record per container, matching its name and known IP addresses. The container cannot alter this record through DHCP.
dynamicallows the containers to self-register in the DNS through DHCP. So whatever hostname the container sends during the DHCP negotiation ends up in DNS.
noneis for a simple recursive DNS server without any kind of local DNS records.
The default mode is
managed and is typically the safest and most convenient as it provides DNS records for containers but doesn’t let them spoof each other’s records by sending fake hostnames over DHCP.
LXD also supports connecting to other hosts using GRE or VXLAN tunnels.
A LXD network can have any number of tunnels attached to it.
production environment usually preferring VLANs for that kind of segmentation.
example of connecting two hosts using VXLAN tunnel:
lion $ lxc network create testbr0 tunnel.lan.protocol=vxlan lion $ lxc network attach-profile testbr0 default eth0
lion will be the one acting as a router for that network, providing DHCP, DNS, … the other hosts will just be forwarding traffic over the tunnel.
tiger $ lxc network create testbr0 ipv4.address=none ipv6.address=none tunnel.lan.protocol=vxlan tiger $ lxc network attach-profile testbr0 default eth0
Now you can start containers on either host and see them getting IP from the same address pool and communicate directly with each other through the tunnel.
this uses multicast, which usually won’t do you much good when crossing routers. For those cases, you can use VXLAN in unicast mode or a good old GRE tunnel.
To join another host using GRE:
lion $ lxc network set testbr0 tunnel.tiger.protocol gre lion $ lxc network set testbr0 tunnel.tiger.local 172.17.16.2 lion $ lxc network set testbr0 tunnel.tiger.remote 172.17.16.9
on "client* host:
tiger $ lxc network create testbr0 ipv4.address=none ipv6.address=none tunnel.lion.protocol=gre tunnel.lion.local=172.17.16.9 tunnel.lion.remote=172.17.16.2 tiger $ lxc network attach-profile testbr0 default eth0
to use vxlan:
lion $ lxc network set testbr0 tunnel.lion.id 10 lion $ lxc network set testbr0 tunnel.lion.protocol vxlan
tiger $ lxc network set testbr0 tunnel.lion.id 10 tiger $ lxc network set testbr0 tunnel.lion.protocol vxlan
The tunnel id is required here to avoid conflicting with the already configured multicast vxlan tunnel.