On Di, 03.05.22 12:07, Jason A. Donenfeld (Jason@xxxxxxxxx) wrote: > I wouldn't be so sure here... Some people have processes around, "always > start out from the same place", like for build machines, and employ a > single VM snapshot that's always rewound after use. It's never forked > into multiple snapshots, but just always goes back to that same starting > point. At sometimes it's futile phantasizing which exotic usecases people might have. > > > >From the perspective of randomness, both of these events imply the same > > > thing. The situation is BAD; reseed immediately. From the perspective of > > > MAC addresses, though, these events would imply different behavior, > > > right? So it seems like vmgenid might need an additional field for this > > > use case. Relatedly, VMware has that prompt where you select about your > > > VM whether, "I moved it" or "I copied it." Presumably something like > > > that would play a part in what is decided as part of this hypothetical > > > second field. > > > > networkd doesn't change MAC addresses in the middle of everything, but > > only when a network interface is downed and upped again. This for > > example happens when a link beat goes away and comes back. In the > > rewind-2min case i'd assume the link beat would probably be restored > > to what it was 2min ago (and thus stay online), but in the clone case > > it would probably drop momentarily and be restored than, to tell > > software to reacquire dhcp and so on. > > That sounds like it's going to be sort of confusing. Let's say we've got > some VM scenario in which rewinds are common due to whatever weird > process (such as a build machine that wants to start out at the same > place each time). During its course of execution, it reboots, or maybe > there's some network connectivity issue and the link goes down. In that > case, when the link comes up, it's going to have a different MAC > address? That doesn't make much sense to me, but maybe I'm missing some > bigger picture detail. It's still better than sticking to the same MAC address for all clones in all cases... Dunno, in systemd the MAC address policies are configurable, for a reason. We'll never find a default that really makes everyone happy. Some people prefer the anonmymity of randomized MAC addresses, others like the stability promises of hashed MAC addresses. We support both policies. I think it would make sense to add a policy that says "stable MAC until the first clone, then random" for example. In fact I think it's a choice that has the chance of being a better default than the current "always stable" approach we employ. So at the very least we should have the option to come up with a policy taking vm generations into account, it's a separate discussion to decide whether to make it opt-in or the default then, and I doubt that part of the discussion really matters here... Lennart -- Lennart Poettering, Berlin
