LXC IP, domain name and recreating experiments

LXD
1

Hi.

I’m developing among other things a Capistrano file, where I have to put a server address: it could be an IP or a domain name.

The server is a LXC, but each time I recreate it, it changes the IP, so I have to update the Capistrano file.

Let’s say the LXC instance name is lxc-instance. By any change does LXD already have a dns so I can get the IP by a name like lxc-instance.lxd.localhost or something like that?

If not… is there a way to use the same IP always, each time I launch the container?

Thanks!

2

If you’re using a managed bridge, such as the default lxdbr0, then yes the instance’s IP is resolvable using <instance_name>.lxd when querying the DNS server running on the bridge’s IP.

See the dns.* settings at Bridge network - LXD documentation

1 Like
3

You are also able to indicate that a specific instance always be allocated the same IP by setting it on the NIC device config, e.g.

lxc config device override instance eth0 ipv4.address=n.n.n.n

See the ipv{n}.address settings at Instance configuration - LXD documentation

1 Like
4

Wasn’t this supposed to update the instance’s /rootfs/etc/systemd/network/eth0.network file with the defined IP? If not what’s the point when DHCP is disabled on the bridge?

5

No, LXD never modifies the guest’s filesystem.

Instead it creates a static DHCP allocation for that NIC’s MAC address in the LXD managed network’s DHCP server so it always gets the same IP via DHCP.

7

Okay, that is sad. Why was it made that way?

I mean on a production env is more common to have everything addressed with static IPs. dnsmasq running just to issue the same DHCP leases over and over again is just a waste of resources for both the host and the container.

So the only way I have to work around this, on a bridge with DHCP disabled, is to manually change the container’s network unit and/or set it up via cloud-init? There isn’t another option built in LXD?

Thank you.

8

That is correct yes.

9

The resources used are pretty minimal, especially given you can increase the lease time with using ipv4.dhcp.expiry, see Bridge network - LXD documentation

10

Because LXD doesn’t know how to configure the guest OS’ files, each one can use different configuration files to control networking.

11

Yes but still requires some kind of DHCP probing inside the container and most likely networking startup delays.

I get that but at the same time it launches the container and changes things / adds volumes etc, why not use the same approach for networking?

I understand the risks associated with having LXD changing the networking file of a container that is already running, however something like continer init > set static ip > start container would make sense.