Attach network to profile

LXD
1

I have a network device attached to “default” profile

$ lxc profile show default
config: {}
description: Default LXD profile
devices:
  eth0:
    nictype: bridged
    parent: lxdbr0
    type: nic
  root:
    path: /
    pool: mars
    type: disk
name: default
used_by:
- /1.0/containers/srv

When I create container using this profile, it doesn’t have such device:

$ lxc launch -p default redis r
Creating r
Starting r
$ lxc config device show r
{}

I can attach it manually

$ lxc network attach lxdbr0 r eth0
$ lxc config device show r
eth0:
  nictype: bridged
  parent: lxdbr0
  type: nic

What is the purpose of attaching it to profile if it is ignored for new containers?

2

lxc config show will not show you anything that’s inherited by a profile.

You’d want: lxc config show --expanded r instead which will show you everything which the container inherits through its profiles.

3

Yes, you’re right:

$ lxc config show --expanded r
architecture: x86_64
config:
  image.architecture: x86_64
  image.description: Ubuntu 16.04 LTS server (20180126)
  image.os: ubuntu
  image.release: xenial
  volatile.base_image: ae88c28613778522f5f0d24dc7e785ef7a248dc21edde2084582773d0430b7bc
  volatile.eth0.hwaddr: 00:16:3e:0b:03:2b
  volatile.eth0.name: eth0
  volatile.idmap.base: "0"
  volatile.idmap.next: '[{"Isuid":true,"Isgid":false,"Hostid":165536,"Nsid":0,"Maprange":65536},{"Isuid":false,"Isgid":true,"Hostid":165536,"Nsid":0,"Maprange":65536}]'
  volatile.last_state.idmap: '[{"Isuid":true,"Isgid":false,"Hostid":165536,"Nsid":0,"Maprange":65536},{"Isuid":false,"Isgid":true,"Hostid":165536,"Nsid":0,"Maprange":65536}]'
  volatile.last_state.power: RUNNING
devices:
  eth0:
    nictype: bridged
    parent: lxdbr0
    type: nic
  root:
    path: /
    pool: mars
    type: disk
ephemeral: false
profiles:
- default
stateful: false
description: ""

Then why this happens?

$ lxc config device set r eth0 ipv4.address 10.100.0.100
error: The device doesn't exist
4

Because there is no device called eth0 directly attached to the container.
If you want to modify an inherited device, you must modify it at the source, which in this case would be by editing your default profile.

Though in the case of ipv4.address, that’s obviously not advisable as it would set the same IP for all containers. When using ipv4.address you must add the device directly to the container.

I do have a branch locally which will introduce a new lxc config device override command to do that for you in one step (so copy the device from the profile into the container config directly and then set some key/values).

5

Thanks, now I see that there are 2 types of devices, inhereted and directly attached.

If lxc config device override command will be required for each container, it will not make big difference, may be only a little bit simplier to remember.

Current way:

lxc launch redis r
lxc network attach lxdbr0 r eth0
lxc config device set r eth0 ipv4.address 10.100.0.100

New command way (if I understood it correctly):

lxc launch redis r
lxc config device override r
lxc config device set r eth0 ipv4.address 10.100.0.100

Maybe it will be better to add new flag to profile which will do the same without any additional commands for each new container?

6

Yeah, having some way of tagging a device in a profile such that it gets copied to the container’s local config at creation time may be interesting (then again it may make things even more confusing :)).

I suspect ideally we’d want to be able to override individual device properties in the container config, so that you could still inherit all the other properties of your network device from the profile but that makes the entire config resolution and validation a bit of a nightmare which is why we decided not to do so initially.