Re: [pve-devel] [PATCH container] fix #3443: setup: clear /etc/machine-id in post-create hook

[Oguz Bektas <o.bektas@proxmox.com>]

On Wed, May 26, 2021 at 12:00:13PM +0200, Thomas Lamprecht wrote:
> On 26.05.21 11:40, Oguz Bektas wrote:
> > so without removing the dbus file we don't get a unique machine-id on container
> > creation, since the templates seem to have a hardcoded id in the dbus path by
> > default. we can also remove that but then we will have to make sure to do that
> > for all the relevant templates
> 
> Yes, but you must check if the dbus one is a symlinlk and if that's the case you
> must not remove it.
> 
> > 
> >>
> >> [0] https://systemd.io/CONTAINER_INTERFACE/
> >>
> >>> note that post_create_hook doesn't run for cloned containers so that
> >>> will need to be handled separately
> >>>
> >>
> >> If you read my post you also read that we must not remove the file in the
> >> clone case.
> > 
> > 
> > yes this hook doesn't run at clone so that's fine.
> > 
> > 
> >>
> >> We currently always generate a new random MAC-address for all netX devies of
> >> a CT on clone, that suggests that we always want to truncate in the clone case,
> >> to ensure that IPv6 SLAAC, among other things, can work OK.
> >>
> >> We could add a "unique" param to the clone call, but until now this was never
> >> requested to be configurable.
> > 
> > looking at the clone_vm api call i wasn't sure where to modify the file during
> > clone.
> > 
> > would it make sense to add this as a config option? we could set this to
> > "uninitialized" in the container config by default. the "unique" param can then
> > decide if the machine-id would be copied or truncated at clone.
> > 
> > i'm open to ideas
> > 
> 
> no, this would never be a config option as it's a flag for a one time action on
> clone, not a permanent configuration relevant for the CT.

sorry i meant here the machine-id as a container config option, and that
the "unique" param could decide the action taken at clone

> 
> The unique flag, if added, would be a basically a copy of the restore "unique"
> flag we already have, but it would default to true for the clone case as we
> basically have that assumption already (for the MAC regeneration).
> 
> But as said, this is optional, the assumption is now already to make relevant
> characteristics like MAC unique on clone, so we could default to that.