I can now access the container on my local network, and I can ping from the container out , so you were correct about the WIFI connection.
It seems to work this morning after powering up the machine, so it just needed some restart care.
The problem now is just the fact that there is large delay after starting the container for it to get the IP address, probably more than 30 seconds.
The IP set in LXD device config only applies if the device is connected to a lxd managed bridge not an external network.
I totally misunderstood, i thought i needed a bridged network to set a static ip (public or private) IP address.
When you do lxc config device set <instance> <nic> ipv{n}.address=<address> LXD creates a static DHCP allocation in its own DHCP server (dnsmasq) for the instance’s MAC address.
So in cases where your instance’s NIC is connected to an unmanaged bridge (that may or may not be connected to the external network), then LXD’s DHCP server isn’t being used and as such the static IP settings in LXD’s config are not consulted.
So with that in mind, and leaving aside any specific implementation details, please can you describe what it is you’re trying to achieve?
Do you just want to get an instance on to the external network with a static IP?
Here at home, i want to run various web applications in instances, and i want these to be available over the local network, e.g. 192.168.1.X.
Then i want to install LXD on a baremetal server, and have a separate public IP address for mail server, and possibly add other applications with their own public IP addresses. Not all containers, just when needed.
If you don’t need the containers that are connected to the external network to be able to communicate with the LXD host (and vice versa) then you can just use a macvlan NIC type, specifying the external interface as the parent. This way you won’t need any unmanaged bridges at all.
lxc config device add <instance> eth0 nic nictype=macvlan parent=<external interface>
Then inside the container, configure its static IP as you would with a normal system.
See https://linuxcontainers.org/lxd/docs/master/instances#nic-macvlan
If you need to the containers to be able to communicate with the host then you will be limited to using either bridged or routed NIC types. The former requires setting up an unmanaged bridge and connecting it to the external interface (see https://netplan.io/examples/#configuring-network-bridges) and then using a bridged NIC type with the parent set to the bridge interface, e.g.:
lxc config device add <instance> eth0 nic nictype=bridged parent=<external interface>
Then inside the container, configure its static IP as you would with a normal system.
See https://linuxcontainers.org/lxd/docs/master/instances#nic-bridged
Keep in mind that for both macvlan and bridged NIC types, the instances will get their own MAC address on the external network (as if they are physically connected to it), and in some production environments (and sometimes when running inside another hypervisor) the number of different MAC addresses per physical port is limited to one.
To get around this we have the routed NIC type which shares the MAC address of the host’s external interface and doesn’t require a separate unmanaged bridge be setup.
The routed NIC type can also be useful in environments where the upstream network doesn’t provide a dedicated subnet of IPs to use, and instead routes non-sequential IPs to your LXD host.
To add a routed NIC type use:
lxc config device add <instance> eth0 nic nictype=routed parent=<external interface> ipv{n}.address=<static ip>
Then inside the container, you need to ensure that either A) the container’s network setup doesn’t remove the static IP and routing added to the NIC by LXD or B) set up the network config to it mirrors the setup added by LXD.
See https://linuxcontainers.org/lxd/docs/master/instances#nic-routed
See How to get LXD containers get IP from the LAN with routed network
Thank you for this detailed answer explaining the types. I had tried to routed nic command but it came back as an error, i found in one of your older posts you added nic after the eth0, this allowed the command to run but still can’t access, going to try again now.
Ah yes I’ve updated that with “nic” now.
When you say communicate with the host, are you referring to communicating with other containers?
Nope, the host (i.e where the LXD process is running). Other containers are fine with macvlan.
Interesting, thanks.
I need my apache container to access the mysql container, i created this profile, dropped the eth0 device on the container, and applied it. The problem is macvlan no longer works, if add lxdbr0 as the second one i was able to get IPV6 address but not version 4. What am i doing wrong?
config: {}
description: ""
devices:
eth0:
name: eth0
network: lxdbr0
type: nic
eth1:
name: eth1
nictype: macvlan
parent: wlx28ee52172bcc
type: nic
name: multi
$ lxc list
+-----------+---------+-----------------------+-----------------------------------------------+-----------+-----------+
| NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS |
+-----------+---------+-----------------------+-----------------------------------------------+-----------+-----------+
| c2 | RUNNING | 10.177.108.109 (eth0) | fd42:6507:3321:8a12:216:3eff:fede:5a06 (eth0) | CONTAINER | 0 |
Can you show me the output of ip a and ip r inside the container, also can you show me the static network config (if any) you’re using inside the container.
root@c2:~# 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
10: eth0@if11: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 00:16:3e:de:5a:06 brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet 10.177.108.109/24 brd 10.177.108.255 scope global dynamic eth0
valid_lft 3468sec preferred_lft 3468sec
inet6 fd42:6507:3321:8a12:216:3eff:fede:5a06/64 scope global dynamic mngtmpaddr noprefixroute
valid_lft 3541sec preferred_lft 3541sec
inet6 fe80::216:3eff:fede:5a06/64 scope link
valid_lft forever preferred_lft forever
12: eth1@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 00:16:3e:c3:c3:2b brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet6 fe80::216:3eff:fec3:c32b/64 scope link
valid_lft forever preferred_lft forever
root@c2:~# ip r
default via 10.177.108.1 dev eth0 proto dhcp src 10.177.108.109 metric 100
10.177.108.0/24 dev eth0 proto kernel scope link src 10.177.108.109
10.177.108.1 dev eth0 proto dhcp scope link src 10.177.108.109 metric 100
jsharief@desktop:~$ lxc info c2
Name: c2
Location: none
Remote: unix://
Architecture: x86_64
Created: 2021/05/11 17:04 UTC
Status: Running
Type: container
Profiles: default, multi
Pid: 3025
Ips:
eth0: inet 10.177.108.109 veth050f084e
eth0: inet6 fd42:6507:3321:8a12:216:3eff:fede:5a06 veth050f084e
eth0: inet6 fe80::216:3eff:fede:5a06 veth050f084e
eth1: inet6 fe80::216:3eff:fec3:c32b wlx28ee52172bcc
lo: inet 127.0.0.1
lo: inet6 ::1
Resources:
Processes: 14
Disk usage:
root: 591.11MB
CPU usage:
CPU usage (in seconds): 2
Memory usage:
Memory (current): 234.11MB
Memory (peak): 245.35MB
Network usage:
eth0:
Bytes received: 9.13kB
Bytes sent: 3.56kB
Packets received: 74
Packets sent: 36
eth1:
Bytes received: 75.92kB
Bytes sent: 1.92kB
Packets received: 293
Packets sent: 22
lo:
Bytes received: 0B
Bytes sent: 0B
Packets received: 0
Packets sent: 0
Please show output of lxc config show c2 --expanded (as lxc info c2 pretty much just shows the same output as ip a)
jsharief@desktop:~$ lxc config show c2 --expanded
architecture: x86_64
config:
image.architecture: amd64
image.description: Ubuntu hirsute amd64 (20210511_07:42)
image.os: Ubuntu
image.release: hirsute
image.serial: "20210511_07:42"
image.type: squashfs
image.variant: default
limits.cpu: "1"
limits.memory: 1GB
volatile.base_image: b1d41f89b9c522048b01ee89b553da39d8eda9f344b6e86049532f02792c265f
volatile.eth0.host_name: veth050f084e
volatile.eth0.hwaddr: 00:16:3e:de:5a:06
volatile.eth1.host_name: macd49f488d
volatile.eth1.hwaddr: 00:16:3e:c3:c3:2b
volatile.eth1.last_state.created: "false"
volatile.idmap.base: "0"
volatile.idmap.current: '[{"Isuid":true,"Isgid":false,"Hostid":1000000,"Nsid":0,"Maprange":1000000000},{"Isuid":false,"Isgid":true,"Hostid":1000000,"Nsid":0,"Maprange":1000000000}]'
volatile.idmap.next: '[{"Isuid":true,"Isgid":false,"Hostid":1000000,"Nsid":0,"Maprange":1000000000},{"Isuid":false,"Isgid":true,"Hostid":1000000,"Nsid":0,"Maprange":1000000000}]'
volatile.last_state.idmap: '[{"Isuid":true,"Isgid":false,"Hostid":1000000,"Nsid":0,"Maprange":1000000000},{"Isuid":false,"Isgid":true,"Hostid":1000000,"Nsid":0,"Maprange":1000000000}]'
volatile.last_state.power: RUNNING
volatile.uuid: f8025666-7172-4503-bc50-87b84a2f455e
devices:
eth0:
name: eth0
network: lxdbr0
type: nic
eth1:
name: eth1
nictype: macvlan
parent: wlx28ee52172bcc
type: nic
root:
path: /
pool: default
size: 5GB
type: disk
ephemeral: false
profiles:
- default
- multi
stateful: false
description: ""
OK thanks.
So the LXD images by default are configured to have eth0 use DHCP (you can see that by looking at /etc/netplan/10-lxc.yaml:
lxc exec c1 -- cat /etc/netplan/10-lxc.yaml
network:
version: 2
ethernets:
eth0:
dhcp4: true
dhcp-identifier: mac
So when your eth0 NIC device is connected to the LXD managed lxdbr0, it will get a private address from that bridge via DHCP.
When you attach another NIC, in this case eth1 as a macvlan connected to your wlx28ee52172bcc interface, the container doesn’t have any automatic configuration, so nothing happens (apart from the IPv6 link local addressing).
So you need to modify your container’s network config inside the container (in this case modifying /etc/netplan/10-lxc.yaml ) to do what you want to do, be it a statically assigned IP or to use DHCP, the same way you would with a real computer. You can also do this configuration automatically using cloud-init (which LXD supports passing config to).
See https://netplan.io/examples/ for more info on using netplan.
Also, you will likely have problems getting macvlan to work with a wifi parent as the different MAC addresses will cause issues with wifi authentication.
Brilliant, thank you.
I copied the code eth0 block in the /etc/netplan/10-lxc.yaml
network:
version: 2
ethernets:
eth0:
dhcp4: true
dhcp-identifier: mac
eth1:
dhcp4: true
dhcp-identifier: mac
Restarted
jsharief@desktop:~$ lxc list
+-----------+---------+-----------------------+-----------------------------------------------+-----------+-----------+
| NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS |
+-----------+---------+-----------------------+-----------------------------------------------+-----------+-----------+
| c2 | RUNNING | 192.168.1.50 (eth1) | fd42:6507:3321:8a12:216:3eff:fede:5a06 (eth0) | CONTAINER | 0 |
| | | 10.177.108.109 (eth0) | | | |
Great, although if you’re using DHCP on both interfaces, you’re likely to get conflicts with the default route as you’ll get one added on both.
I am not following, re the conflict as they are on different networks and different cards, does that count?