Changing instance-id cloud-init

[flori]

Hello community,

today I had the strange effect, that the ssh host keys one of my VMs had changed. After digging a bit into the logs I figured out that the cloud-init instance-id had changed and thus cloud-init simply cleaned everything.

Is there anyone who has experienced something similar?

Thanks!

 

[jtracy]

I just ran into a similar issue today. I was working on some networking in ansible and needed a VM that I could snapshot and revert for testing.

I was under the impression that it did not completely reconfigure things like ssh keys on reconfigure, but I guess it does.

For a little more info I found this email thread discussing it: https://lists.proxmox.com/pipermail/pve-devel/2018-March/031169.html

 

[flufsor]

Sorry to bump this thread, but did anyone find a fix for this?

 

[blueberry]

From the linked mail thread:

the only thing not really clear is how we generate instance-ids

currently it is the hash of the config, so a config change means a new
instance-id (which triggers things as ssh-host key generation etc.)

It seems this way of generating instance_id has not changed since 2018, as all our VMs got new SSH host keys after the DNS config of the host was changed. This is obviously a very bad thing and causes all sorts of breakage.

Workarounds seem to be

• Uninstall cloud-init in the VM after initial deployment
• Disable first-boot-detection by setting manual_cache_clean: true (https://cloudinit.readthedocs.io/en/latest/topics/boot.html#first-boot-determination)
• Forbid cloud-init from touching the host key after initial deployment, so that things like network config can still be changed via cloud-init. Write ssh_deletekeys: false into /etc/cloud/cloud.cfg.

 

[trident1451]

Another workaround is to override the instance-id.

You can find the current instance-id using qm cloudinit dump <vmid> meta. This can then be saved as a snippet to override the automatically generated meta data using qm set <vmid> --cicustom meta=local:snippets/<yaml file with instance-id defined>.yaml

It would be nice if the cloud-init instance-id was tied to the vmgenid instead of a hash of the cloud-init config file. If you perform the workaround above after your actual first boot, it should retain the same instance-id even other cloud-init information changes.