The risk is the meaning/usage of that key may change in the future with no warning.
Generally speaking you should try and only use keys that are documented for external use, e.g. https://linuxcontainers.org/lxd/docs/master/instances#nictype-bridged
I’m not sure what you mean about public IP addresses, what is the use-case for needing to specify MAC address via volatile?
At OVH or hetzner, you can only assign a public IP address to a MAC address that you receive/generate from their control panels. It’s not possible to assign the public ip without static MAC address.
That’s fine, you can specify a static MAC address you’ve been allocated without using volatile using the command I mentioned above, the hwaddr key is documented and supported for static MAC addresses on a NIC device:
lxc config device set <container> <nic> hwaddr <mac address>
I prefer this method to prevent the missing device error:
lxc config device add <CT> eth0 nic nictype=macvlan parent=<host-nic> hwaddr=<mac>
After that it’s possible to use your command. The volatile key is easier in this case, but ok. I understand you can change it later. I will keep this in mind.
Yes that command is valid also, its setting the hwaddr at the same time the macvlan NIC is added (overriding the eth0 NIC from the profile).
eth0 is inherited from the macvlan profile, so it’s not possible to use:
lxc config device set <container> <nic> hwaddr <mac address>.
The best way is in my opinion to delete the macvlan profile and add eth0 to the specific container. It’s not possible to add the MAC addresses to the macvlan profile in this case.
If we use a macvlan configuration without a volatile option, we get Error: The device doesn't exist
So if i’m right:
Remove macvlan profile from your container. You dont need it anymore:
lxc profile remove <ct> macvlan
Delete the profile:
lxc profile remove macvlan
Override NIC from default profile:
lxc config device add <CT> eth0 nic nictype=macvlan parent=<host-nic> hwaddr=<mac>
And then it should work fine.
@tomp thank you for pointing out that we shouldn’t use the volatile keys, but is there a recommendation for using IPv6 with macvlan ?
I noticed that in his posts since 2018 @stgraber has been offering examples with the “routed” method instead of “macvlan”.
So is “routed” fully supported under Ubuntu 18.04 and LXD 3.0.3 or do I need to install a newer LXD with snapd?
It seems to me that all providers (Hetzner, OVH etc) by default simply route all your IPs/Nets to your dedicated server NIC and offer a custom MAC only as a secondary option (for VMware etc).
Thank you in advance, K.
Yes, you can try it with routes. But I dont like individual profiles for containers. Macvlan is easy to configure with only 1 command to override eth0. (to receive DHCP)
You need LXD 3.19 for this feature:
And yes, you can use your host MAC (by default) to route it to your containers.
lxc config device add c1 eth0 nic nictype=routed ipv4.address=public ip
I agree that macvlan seems (is?) the easiest to configure, but as I wrote earlier I had inexplicable networking problems when I removed the Hetzner secondary MAC address (for additional IP) from one container and adding it to another container (on a Ubuntu 18.04 host with LXD 3.0.3).
This experience has made me hesitant to use it in production … 
I have not experienced that myself. It always works here. Anyway, it is time for you to update LXD 
If anyone knows the answers to 2 questions please:
Can I use IPv6 in a container configured with macvlan ? (I’ve asked this twice above)
Should I be afraid of trouble in the future (e.g. upon reboot or adding/removing macvlan containers etc) if I have already configured my macvlan containers with the volatile key ? (i.e. using lxc config set myct volatile.eth0.hwaddr xyz instead of the syntax suggested by @TomvB )
Thank you in advance, K.
Thank you, but neither of the links answer my questions …
And if they do this… You can of course delete it from the containers… But change the volatile key now as you can. Do not wait too long.
Thanks.
My question was should I re-do the macvlan configs of the already running containers ??? (i.e. reconfigure them based on your post #24) Those CTs have been configured with the old/wrong syntax of volatile keys and I want to avoid any surprises in the future e.g. if I upgrade from LXD 3.0.3 to a newer version …
And just as you pointed out in your earlier post, I get an error when I try the syntax of @tomp :
$ lxc config device set ct02 eth0 hwaddr 00:50:51:52:53:54
Error: The device doesn't exist
PS: Sorry for being persistent, but I know nothing about the internals of LXD and there is no config text file to read like most other tools.
lxc config unset <CT> volatile.eth0.hwaddr
And then this:
So, to summarize, the instructions in the first few posts of this thread (recommending to set volatile.eth0.hwaddr ) are incorrect and may cause problems in the future.
Let’s just hope that new visitors looking for clues will read the entire thread all the way down to here …
Not incorrect, but may cause problems in the future with upcoming changes.
Btw unset <CT> volatile.eth0.hwaddr doesn’t seem to change anything in the config:
$ lxc config unset ct02 volatile.eth0.hwaddr
$ lxc config show ct02 --expanded | fgrep hwaddr
volatile.eth0.hwaddr: 00:50:51:52:53:54
$
PS: I also got an error when I tried lxc profile remove macvlan so I’ve given up and reverted to the old “volatile” config and just made notes to be extra careful before upgrading LXD in the future.