In LXC, I recall that one could instruct Dnsmasq to “ignore” a specific container via its name or fixed mac address. In LXD, overriding the inherited profile with ipv4.address: none causes the container to acquire a random IP, rather than none.
I reckon raw.dnsmasq might work, but is there an LXD-style way of (temporarily) giving the container a nic without making it part of the network?
No, it’s within the LXD bridge’s IP range, which is 10.200.0.0/24 in my case. So it simply behaves as if I hadn’t set a fixed IP in my container config. The DHCP lease doesn’t seem to be relevant. If I change the MAC (hwaddr), I can get the container to acquire a different random IP.
One thing that does work is setting the following in the bridge YAML:
raw.dnsmasq: dhcp-host=c1,ignore
But only if I explicitly setipv6.address: none in the container as well, even though the bridge already carries that setting. If I omit the latter option, the container will acquire a random IPv4 (!) address, as described in my first post.
So to summarize:
c1.device.eth0.ipv4.address: none → Random IP
c1.device.eth0.ipv4.address: none + bridge.config.raw.dnsmasq: dhcp-host=c1,ignore → Random IP
c1.device.eth0.ipv4.address: none + c1.device.eth0.ipv6.address: none → Random IP
c1.device.eth0.ipv4.address: none + c1.device.eth0.ipv6.address: none + bridge.config.raw.dnsmasq: dhcp-host=c1,ignore → No IP (as desired)
Not sure how this interaction can be explained. If you’re aware of a more straight forward LXD toggle, I’d still be glad to learn about it!
Sorry to bump this thread, bu could the developers comment on whether it’s intended behavior that setting ipv4/6.address: none results in a random IP for the specified interface, rather than none?
To me, the documentation reads like that should not be the case:
IPv4 address for the bridge (CIDR notation). Use “none” to turn off IPv4 or “auto” to generate a new one
I would have assumed that auto → random IP, and none → no IP.
You do not have a managed network interface by LXD, but that does not preclude some other service to interject and provide DHCP leases to a container that asks for them.
This is expected behaviour.
The different subnet of the IP strongly hints that something else is giving out IPs.
The different subnet of the IP strongly hints that something else is giving out IPs.
It’s the subnet of the LXD bridge, as I wrote in my first reply. I doubt that changing raw.dnsmasq would have the effect it has, if the IP came from somewhere else.
$ lxc network show lxdbr0
config:
ipv4.address: 10.200.0.1/24
ipv4.dhcp: "true"
ipv4.firewall: "false"
ipv4.nat: "false"
ipv4.routing: "true"
ipv6.address: none
ipv6.dhcp: "false"
description: ""
name: lxdbr0
type: bridge
used_by:
- /1.0/containers/c1
managed: true
status: Created
locations:
- none
$ lxc config show c1
(…)
devices:
eth0:
ipv4.address: none
ipv6.address: none
nictype: bridged
parent: lxdbr0
type: nic
(setting fixed hwaddr here made no difference either)
$ lxc list c1
+---------+---------+---------------------+------+------------+-----------+
| NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS |
+---------+---------+---------------------+------+------------+-----------+
| c1 | RUNNING | 10.200.0.121 (eth0) | | PERSISTENT | 0 |
+---------+---------+---------------------+------+------------+-----------+
Bump. Would someone be so kind to confirm/deny my conclusion? The container’s IP certainly comes from the dnsmasq daemon spawned by LXD.
If you can spin up a container that has ipv4.address: none and ipv6.address: none in its type: nic device without it acquiring some IP, then I’m glad to be proven wrong. If none never meant to imply “no IP”, then let me know. Since auto exists, I’d assume it does.
P.s. I’m using the LXD 3.0.3 stable release, if that matters.
can you do a check with an image downloaded from the images: repo ? these images do not have the cloud-init features. If it works then, all you have to do is to find the incantation to disable the cloud-init network setting when connected to a bridge. That’s just an idea, I’m not using anythink like your config myself.
edit: thinking twice, even if these images do not have cloud init, they could have still default dhcp networking. It’s quite common on standard distros.
not adding any network device to the container, therefore the container does not have access to lxdbr0 or anything related to networking. To make it usable, you may use proxy devices.
create a managed network device that does not request a DHCP lease.
For the latter, you would need to create an additional (managed) network device, let’s say, lxdbr1, with the configuration
$ lxc network show lxdbr1
config:
ipv4.address: none
ipv4.nat: "false"
ipv6.address: none
ipv6.nat: "false"
description: "Has a network device but does not get offered a DHCP lease"
...
Then, create a new LXD profile and make it to use lxdbr1.
Finally, launch a new container using the new LXD profile.