I’m using Ubuntu Server 16.04 with LXD 2.0.11. This is a fresh install for testing purposes on bare metal.
Following the official guide, I created a container successfully, so there is no general issue with the configuration.
I have not changed the profiles, there are ‘default’ and ‘docker’. The ‘default’ profile is using lxdbr0 which is handing out addresses from a pool that was generated at random, I created container C1 that’s using it and I could connect to it fine.
What I’m trying to achieve now is to create containers that are in the same subnet as my host. From what I could find out so far, there are two ways of achieving that. Either I simply set the nictype to macvlan, or I create a new bridge that I reference in the configuration. Network configuration can be done either on a container directly or using a profile. Any changes in the container will override the profile. As this is just a test on a single container, I decided to do the change on the container directly.
At the moment, I’m stuck with the nictype=macvlan option and hope someone can help me out with this. I did the following on container C1:
$ sudo lxc stop C1
$ sudo lxc config device add C1 eth0 nic nictype=macvlan parent=eno1 ### eno1 being my host nic with a static IP address 'iface eno1 inet static'
$ sudo lxc start C1
In my understanding, C1 should now be getting an IP from my local dhcp server (which is not on the host machine, by the way - I understand that wouldn’t work with macvlan), but it’s not.
What could be the issue? Do I have to somehow manually kickstart the dhcp client in the container or is something else entirely?
You can make your non-root user account to be a member of the lxd group, and then you can run the lxc commands without sudo.
It is possible that your non-root account is already member of lxd. Run groups to check whether lxd is listed in there.
If you are not member of the lxd group, here is how to add your account to the group,
When you log in again, your non-root account (let’s say, myusername) will be able to run lxc command without root.
Having said that, the command you have showed is fine. When you restart the container, it should get an IP address from the LAN DHCP server.
To verify,
You do not mention whether the container gets an IP address at all or whether it gets an IP address from LXD’s dnsmasq.
Another potential issue is that, if your host connects to the local network over WiFi (with encryption?), then the WiFi router does not accept more than one MAC address from the same secure connection.
Yet another potential issue is that some LAN routers may take their time in handing out an IP address. Can take 10 or more seconds.
This container is not getting any IP address, at all.
$ lxc list
+-----------+---------+------+------+------------+-----------+
| NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS |
+-----------+---------+------+------+------------+-----------+
| C1 | RUNNING | | | PERSISTENT | 0 |
+-----------+---------+------+------+------------+-----------+
My host is connected via cable to a WiFi bridge that in turn is connected to the router. I have several devices connected to that WiFi bridge and they all connect fine.
Any other configuration options on the host I might be missing?
I’ve seen this kind of behavior before and it’s usually either some kind of MAC filtering somewhere or a problem with macvlan support on the underlying NIC.
I don’t know how well macvlan works with the tg3 (broadcom?) wired driver and it’s not super easy to check because of the way macvlan works… The easiest way to see what’s going on would be to run tcpdump on that wireless bridge to see whether any packet from the container actually makes it out of your server’s NIC.
tcpdump on the server itself is useless as traffic from a macvlan won’t show up when dumping its parent…
Sorry for the late reply, I had to choose the right moment to break open my wifi gateway when I wouldn’t depend on it. And it then took me quite a while to understand how to navigate and configure OpenWRT. I set it up more than 3 years ago and never again had another look.
As I can now confirm, the problem is with the gateway. It’s not properly relaying dhcp messages even though it seems correctly configured. So, the lxc container indeed sends out a dhcp discover message and the server returns an offer but that offer gets stuck at the gateway.
So my issue has nothing to do with macvlan being the nictype. If my gateway would properly relay the broadcasted messages, it would work.
I hope it’s ok if I ask a follow up question. Now that it became clear that I cannot use my dhcp server to assign static leases, is there another, maybe more direct way that I could give lxc containers static IPs in the same subnet as the host? It was easily possible using lxc1 but I can’t seem to find a straightforward way of doing it with lxd.
The preferred way to feed the static IP configuration to the container is using cloud-init’s network-config which can be passed through the user.network-config LXD config key.
This does assume a cloud-init enabled image though, like ubuntu:16.04 for example.
Another option is to use raw.lxc to set the ipv4/ipv6 config directly on the container’s interface, but that’s not something we usually recommend as not all distros deal too well with such pre-configured networking.
