Hm ok i added also auto eth0. But eth0 in the contaier still has no ip (output form ifconfig -a). As if the settings in container/etc/network/interfaces would not affect the eth0 interface.
its silly because if i use the default profile the eth0 interface in the container gets an ip independently what is set in the inetrfaces file on the container:
eth0 from the cotainer with profile “default” is set
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 138.201.151.51 netmask 255.255.255.248 broadcast 138.201.151.55
inet6 fd43:1f19:80ac:e49c:216:3eff:fe2d:2b0a prefixlen 64 scopeid 0x0<global>
inet6 fe80::216:3eff:fe2d:2b0a prefixlen 64 scopeid 0x20<link>
ether 00:16:3e:2d:2b:0a txqueuelen 1000 (Ethernet)
RX packets 48 bytes 9938 (9.9 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 65 bytes 5567 (5.5 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0Can you put the default profile?
Proof this:
- stop the container
- lxc assign default,bridge <-- assigns two profiles. You can change the list of profiles which apply to a given container and the overlapping parameters will take a value from the last applied profile.
- start the container and verify if container has IP and connection
Maybe i should delete the lxdbr0 bridge?
$ ifconfig -a
br0 Link encap:Ethernet HWaddr f8:32:e4:71:a1:d8
inet addr:136.243.106.231 Bcast:136.243.106.255 Mask:255.255.255.192
inet6 addr: fe80::fa32:e4ff:fe71:a1d8/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:5756 errors:0 dropped:0 overruns:0 frame:0
TX packets:6807 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:833070 (833.0 KB) TX bytes:5281455 (5.2 MB)
eth0 Link encap:Ethernet HWaddr f8:32:e4:71:a1:d8
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:7681 errors:0 dropped:0 overruns:0 frame:0
TX packets:6898 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1023461 (1.0 MB) TX bytes:5297509 (5.2 MB)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:10 errors:0 dropped:0 overruns:0 frame:0
TX packets:10 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:968 (968.0 B) TX bytes:968 (968.0 B)
lxdbr0 Link encap:Ethernet HWaddr fe:a8:91:87:55:2f
inet addr:138.201.151.49 Bcast:0.0.0.0 Mask:255.255.255.248
BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:3389 errors:0 dropped:0 overruns:0 frame:0
TX packets:3996 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:4972396 (4.9 MB) TX bytes:700742 (700.7 KB)
vethD3HALI Link encap:Ethernet HWaddr fe:a8:91:87:55:2f
inet6 addr: fe80::fca8:91ff:fe87:552f/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:249 errors:0 dropped:0 overruns:0 frame:0
TX packets:1214 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:17932 (17.9 KB) TX bytes:310556 (310.5 KB)
vethUCBS8R Link encap:Ethernet HWaddr fe:79:9d:59:a2:2c
inet6 addr: fe80::fc79:9dff:fe59:a22c/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:17 errors:0 dropped:0 overruns:0 frame:0
TX packets:181 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:3183 (3.1 KB) TX bytes:11362 (11.3 KB)OK I assigned the two profiles but the container doesnt get an IP adress.
$ sudo lxc list
+------+---------+-----------------------+-----------------------------------------------+------------+-----------+
| saul | RUNNING | | | PERSISTENT | 1 |
+------+---------+-----------------------+-----------------------------------------------+------------+-----------+It isn’t necessary delete but I would change the values for lxdbr0 (to not use the same network for lxdbr0 and for containers in bridge mode with br0).
Lxdbr0 is like a NAT network in Virtualbox; that is to say, containers in that network will receive a IP via an internal dhcp server (lxd do this) and they will be able to access internet via iptables (doing SNAT through the public IP of the host). Services running in those container only will be accessible via iptables DNAT. You can see NAT rules via: sudo iptables -t nat -L -n . In my computer:
manuel@pcmanuel:~$ sudo iptables -t nat -L -n
[sudo] password for manuel:
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
MASQUERADE all -- 10.0.0.0/24 !10.0.0.0/24 /* generated for LXD network lxdbr0 */
You can change the lxdbr0 values with: lxc network edit lxdbr0
I have a bridge br0 and lxdbr0 without problems (and even more internal networks). Some containers work in bridge mode with br0 (they require a real IP config for the lan network) and others in bridge mode with lxdbr0.
OK i edited the /etc/default/lxd-bridge file manually (lxc network command is missing in lxd 2.0 i guess) and restarted the bridge. Now the container is getting an IP from 10.0.8.0/24 range in default profile. But it didnt solved the problem. The container doesnt still get an IP with bridge profile attached.
this is also my default profile:
config:
environment.http_proxy: ""
user.network_mode: ""
description: Default LXD profile
devices:
eth0:
name: eth0
nictype: bridged
parent: lxdbr0
type: nic
name: default
used_by: []I also created a macvlan profile now. But the container also doesnt get an IP.
Container interfaces file:
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
address 138.201.151.50/29 <--- My subnet wit pubic IP´s
gateway 136.243.106.231 <--- IP Adress of the Host
dns-nameservers 8.8.8.8 8.8.4.4
Host interfaces file:
source /etc/network/interfaces.d/*
auto lo
iface lo inet loopback
iface lo inet6 loopback
auto eth0
iface eth0 inet static
address 136.243.106.231 <--- Host public IP
netmask 255.255.255.192
gateway 136.243.106.193
up route add -net 136.243.106.192 netmask 255.255.255.192 gw 136.243.106.193 dev eth0
iface eth0 inet6 static
address 2a01:4f8:171:fe6::2
netmask 64
gateway fe80::1
macvlan profile
config:
environment.http_proxy: ""
user.network_mode: ""
description: LXD macvlan profile
devices:
eth0:
name: eth0
nictype: macvlan
parent: eth0
type: nic
name: macvlan
used_by: []
default profile
config:
environment.http_proxy: ""
user.network_mode: ""
description: Default LXD profile
devices:
eth0:
name: eth0
nictype: bridged
parent: lxdbr0
type: nic
name: default
used_by: []Hi,
I tried your profiles and interface file in my computer and they worked (both the macvlan profile and bridge profile). Both the host and container are Ubuntu 16.04.4 LTS.
My lxd version is 2.21 from backports repositories
oh thats cool :-D. Thank you! Unfortunately here its not working! Struggeling all the time but have no idea at the moment where is the bug. Maybe it has to do with network settings of my hoster? This is a root server from hetzner.de (no virtual machine). Another probem might be that the IP of the host bridge br0 is not in the subnet which I use for the containers?
server IP is 136.243.106.231
gateway 136.243.106.193
ip´s for the container: 138.201.151.48/29
@simos has a lot of tutorials about LXD and two of them are about Hetzner:
Maybe, you see something we do not see.
Another probem might be that the IP of the host bridge br0 is not in the subnet which I use for the containers?
No, in labs with my pupils I have a bridge br0 and I created a lot of containers with IPs from different networks. The container should catch the IP, netmask, gateway and dns from interface file. The only thing I see strange is the gateway for the container ( 136.243.106.231) because it’s in a different network.
yes i will check the blog posts from @simos again - i have read there today a bit.
Can i install the backporst over my existing lxd installation with
apt install -t xenial-backports lxd lxd-client
without affecting my running containers?
You are trying to set up on a dedicated server (Hetzner calls them rootservers).
You need to know what technical requirements exist, when your dedicated server has more than one IP address. Do you assign them statically to your VMs/containers or is there a DHCP server that will answer to DHCP requests from your VMs/containers?
If you can find documentation on Hetzner on how to use multiple public IP addresses on a dedicated server, then that would be enough to give you help.
Thank you @simos i found some instructions here: https://wiki.hetzner.de/index.php/Zusaetzliche_IP-Adressen/en
I will check that. But dont know if i will get all of it right - but will try 
Hi @henrik!
My understanding from the Hetzner documentation is this:
-
You have a dedicated server, and using Hetzner Robot, you have asked and got Additional IP addresses.
-
At the Hetzner Robot / Additional IP page, you can set MAC addresses for each IP. You need to do so.
Assign MAC addresses that start with00(i.e. 00:01:02:03:04:05). -
In LXD, set the MAC address of the containers accordingly, using the command
lxc config set c1 volatile.eth0.hwaddr 00:01:02:03:04:05
That’s it. Follow the bridge or macvlan tutorials and your containers should be able to get their IP address from the Hetzner DHCP server.
Hi @simos, thanks again for your help. I ordered a subnet - so i dont get MAC adresses for the subnet. Thats what Hetzner writes:
Subnets:
For the use of IPs in a subnet with a virtualization solution that does not have routing capabilities a VM is necessary to perform this function. The subnet must then be routed on this VM.
Thats what I´m doing at the moment i created the subnet wih LXD for this Ip adresses and the containers are getting IP´s from the lxd DHCP Server. This is what I wanted to change because i had issues eg. that after reboot the IP Adresses where changed or different IP adresses where assigned. Also if i restart the bridge configuration the IPs getting mixed up and I have no option to define which container should get which IP.
I would love to try it out but Hetzner does not offer additional IP to their cloud servers (which I can try quickly).
I would still consider that setting a permanent MAC address for each container would fix issues, even with the subnet.
ok but for subnets hetzner does not provide mac adresses (as they write in the howtos). I coud give you ssh credentials to the server if you want 
then you could check …