On Mo, 02.05.22 20:04, Jason A. Donenfeld (Jason@xxxxxxxxx) wrote: > > I can just tell you, that in systemd we'd have a usecase for consuming > > such a generation counter: we try to provide stable MAC addresses for > > synthetic network interfaces managed by networkd, so we hash them from > > /etc/machine-id, but otoh people also want them to change when they > > clone their VMs. We could very nicely solve this if we had a > > generation counter easily accessible from userspace, that starts at 0 > > initially. Because then we can hash as we always did when the counter > > is zero, but otherwise use something else, possibly hashed from the > > generation counter. > > This doesn't work, because you could have memory-A split into memory-A.1 > and memory-A.2, and both A.2 and A.1 would ++counter, and wind up with > the same new value "2". Yes, that's why I as vague about what to switch to if the counter is non-zero, i.e. "something else, *possibly* hashed…". For this MAC address usecase it's entirely sufficient to be able to distinguish if the system was closed at all, i.e. if the counter is zero or is non-zero. Because that would already be great for a policy of "hash it in a stable way from /etc/machine-id, if counter == 0" + "use random MAC once counter > 0". Such a MAC address policy I think should probably even be the new default in networkd, if we could implement it. For that we'd need a single bit of info from the kernel, indicating whether the sysem was cloned at all. i.e. if the vmgenid uuid is different from the one the system booted up first. Lennart -- Lennart Poettering, Berlin
