Resetting machine-id at runtime would be a pretty big break from current expectations, and correct implementation would require foreknowledge of services using machine-id that are provided in an image. The potential for bugs due to implementation complexity, potential for boot speed regression caused by services delaying until after machine-id is reset, and expected future burden of such a feature due to changes in services and variation in Ubuntu and other distros makes the perceived risk of this feature outweigh the benefit. These complexity, risk, and potential boot speed issues are not present when machine-id is correctly set at boot time, so I'm hesitant to move forward with this request.
I'll mark this "Won't Fix" for now. In the meantime, I'd like to point users experiencing the same issue towards our build recommendation[1], specifically the --machine-id option. [1] https://cloudinit.readthedocs.io/en/latest/reference/cli.html#clean ** Changed in: cloud-init Status: New => Won't Fix -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/2003121 Title: machine-id is not reset when instance-id changes Status in cloud-init: Won't Fix Bug description: As discussed in #ubuntu-server just now, it's expected that cloud-init will ensure that machine-id is not carried over when a VM is cloned and this is detectable by an instance-id change. This would align behaviour with ssh host key regeneration behaviour. Actual behaviour: currently if a VM is cloned and the instance-id changes, /etc/machine-id remains the same. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/2003121/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp