Prevent container from acquiring IP?

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?

Does that random IP address look like 169.254.?.?

No, it’s within the LXD bridge’s IP range, which is 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 set ipv6.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:

  1. c1.device.eth0.ipv4.address: none → Random IP
  2. c1.device.eth0.ipv4.address: none +
    bridge.config.raw.dnsmasq: dhcp-host=c1,ignore → Random IP
  3. c1.device.eth0.ipv4.address: none +
    c1.device.eth0.ipv6.address: none → Random IP
  4. 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! :slight_smile:

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

  ipv4.dhcp: "true"
  ipv4.firewall: "false"
  ipv4.nat: "false"
  ipv4.routing: "true"
  ipv6.address: none
  ipv6.dhcp: "false"
description: ""
name: lxdbr0
type: bridge
- /1.0/containers/c1
managed: true
status: Created
- none

$ lxc config show c1

    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 | (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.


There are two options here,

  1. 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.
  2. 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
  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.

Ok, thanks for clarifying. I wanted to make sure I’m not missing anything. I’ll do it one of these ways then. :+1: