Extend profile with container-specific settings?

LXD
1

I have several containers using a profile called “macvlan”; this profile is basically just the default profile, but instead of a bridged ethernet it uses a macvlan-device. I use a profile for this, so I can easily move the containers between servers without any extra steps needed; on e.g. server1, the profile is set to use enp4s0 as the parent-device and on server2 it’s set to use enp0s25 – all I need to do to move a container from one to another is “lxc stop containerHere && lxc move containerHere server2:containerHere && lxc start server2:containerHere”

Alas, this setup changes the MAC-address those containers use and I can’t specify the MAC-address in the profile, since the profile is used by multiple containers. Also, it would appear that LXD doesn’t allow me to “extend” the profile with container-specific settings, like e.g. “lxc config set containerHere eth0.hwaddr=macAddressHere” doesn’t work, since the NIC is configured in the profile instead of in the container’s own config.

Now, I realize there may be better ways of doing what I’m doing and I’ll happily listen to any suggestions, but I also wonder: is there any way of specifying devices, like e.g. NICs, in a profile and then configure container-specific settings for those devices in the container’s own config? Could this be something to add in a future version of LXD?

Addendum: at the moment, when moving a container from one server to another, I have to add the extra step of “lxc config set remoteServer:containerHere volatile.eth0.hwaddr=$(lxc config get containerHere volatile.eth0.hwaddr)”, which works, but is kinda clunky.

EDIT: I just realized that I should just make a MACVLAN-network using “lxc create network” and use that, instead of profiles. Welp, that renders this question both stupid and redundant.

2

Hi!

lxc network create will create a managed (by LXD) network, not a network that the container will get an IP address from the LAN.

However, since LXD 4.4, it is possible to have managed macvlan. See more at LXD 4.4 has been released

3

There must be some sort of a misunderstanding here, since I just used “lxc network create --type=macvlan parent=nichere” to create an LXD-managed MACVLAN-network.

4

That’s odd, the difference between lxc copy and lxc move is that the latter retains volatile config keys.

stgraber@castiana:~/data/code/lxc/lxd (lxc/master)$ lxc init images:alpine/edge a1
Creating a1
stgraber@castiana:~/data/code/lxc/lxd (lxc/master)$ lxc config show a1
architecture: x86_64
config:
  image.architecture: amd64
  image.description: Alpine edge amd64 (20200920_13:00)
  image.os: Alpine
  image.release: edge
  image.serial: "20200920_13:00"
  image.type: squashfs
  volatile.apply_template: create
  volatile.base_image: d2619471089c8bafb4c6936312ec074d446f201a3cee0cc8efa361886b866de4
  volatile.eth0.hwaddr: 00:16:3e:1c:d7:c2
  volatile.idmap.base: "0"
  volatile.idmap.next: '[{"Isuid":true,"Isgid":false,"Hostid":1000000,"Nsid":0,"Maprange":1000000000},{"Isuid":false,"Isgid":true,"Hostid":1000000,"Nsid":0,"Maprange":1000000000}]'
  volatile.last_state.idmap: '[]'
devices: {}
ephemeral: false
profiles:
- default
stateful: false
description: ""
stgraber@castiana:~/data/code/lxc/lxd (lxc/master)$ lxc copy a1 s-sateda:a1 --mode=relay
stgraber@castiana:~/data/code/lxc/lxd (lxc/master)$ lxc config show s-sateda:a1
architecture: x86_64
config:
  image.architecture: amd64
  image.description: Alpine edge amd64 (20200920_13:00)
  image.os: Alpine
  image.release: edge
  image.serial: "20200920_13:00"
  image.type: squashfs
  volatile.apply_template: copy
  volatile.base_image: d2619471089c8bafb4c6936312ec074d446f201a3cee0cc8efa361886b866de4
  volatile.idmap.base: "27000000"
  volatile.idmap.next: '[{"Isuid":true,"Isgid":false,"Hostid":27000000,"Nsid":0,"Maprange":1000000},{"Isuid":false,"Isgid":true,"Hostid":27000000,"Nsid":0,"Maprange":1000000}]'
  volatile.last_state.idmap: '[]'
devices: {}
ephemeral: false
profiles:
- default
stateful: false
description: ""
stgraber@castiana:~/data/code/lxc/lxd (lxc/master)$ lxc config set s-sateda:a1 security.protection.delete=false && lxc delete s-sateda:a1
stgraber@castiana:~/data/code/lxc/lxd (lxc/master)$ lxc move a1 s-sateda:a1 --mode=relay
stgraber@castiana:~/data/code/lxc/lxd (lxc/master)$ lxc config show s-sateda:a1
architecture: x86_64
config:
  image.architecture: amd64
  image.description: Alpine edge amd64 (20200920_13:00)
  image.os: Alpine
  image.release: edge
  image.serial: "20200920_13:00"
  image.type: squashfs
  volatile.apply_template: copy
  volatile.base_image: d2619471089c8bafb4c6936312ec074d446f201a3cee0cc8efa361886b866de4
  volatile.eth0.hwaddr: 00:16:3e:1c:d7:c2
  volatile.idmap.base: "27000000"
  volatile.idmap.next: '[{"Isuid":true,"Isgid":false,"Hostid":27000000,"Nsid":0,"Maprange":1000000},{"Isuid":false,"Isgid":true,"Hostid":27000000,"Nsid":0,"Maprange":1000000}]'
  volatile.last_state.idmap: '[]'
devices: {}
ephemeral: false
profiles:
- default
stateful: false
description: ""
5

Can you show us a reproducer of the volatile.eth0.hwaddr changing or being removed when doing lxc move please?

6

I must have used copy, instead of move when I had it happen. At least I can’t make it happen at the moment. Besides which, that wasn’t really the point with this thread in the first place, since I want to be able to retain the hwaddr regardless of whether I am moving or copying the containers.

7

In that case you can do this to copy the device from the profile into the instance and modify its hwaddr setting:

lxc config device override <instance> <device> hwaddr=<mac address>

After that if you need to modify it in the future you can do:

lxc config device set <instance> <device> hwaddr=<mac address>