From: Thomas Lamprecht <t.lamprecht@proxmox.com>
To: Oguz Bektas <o.bektas@proxmox.com>,
Proxmox VE development discussion <pve-devel@lists.proxmox.com>
Subject: Re: [pve-devel] [PATCH container] fix #3443: setup: clear /etc/machine-id in post-create hook
Date: Wed, 26 May 2021 12:00:13 +0200 [thread overview]
Message-ID: <f3ee367a-4aba-f025-9d78-3364db34315e@proxmox.com> (raw)
In-Reply-To: <20210526094023.GB14375@gaia.proxmox.com>
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.
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.
next prev parent reply other threads:[~2021-05-26 10:00 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-25 13:17 Oguz Bektas
2021-05-25 13:45 ` Thomas Lamprecht
2021-05-26 9:40 ` Oguz Bektas
2021-05-26 9:46 ` Oguz Bektas
2021-05-26 10:00 ` Thomas Lamprecht [this message]
2021-05-26 10:03 ` Oguz Bektas
2021-05-26 10:07 ` Thomas Lamprecht
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f3ee367a-4aba-f025-9d78-3364db34315e@proxmox.com \
--to=t.lamprecht@proxmox.com \
--cc=o.bektas@proxmox.com \
--cc=pve-devel@lists.proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox