Hacker News Reader

Comment by lima | Hacker News Reader

virt-clone only takes care of the libvirt config but won't touch unique identifiers in your disk image.

/etc/machine-id isn't the only thing to worry about when duplicating a VM - think SSH host key, DHCP leases, various filesystem UUIDs, log files, MAC addresses in ifcfg-* files and udev-persistent-net rules...

You can use virt-sysprep[1] to clean up a disk image.

[1]: https://www.libguestfs.org/virt-sysprep.1.html

View on HN

Cloning VMs is kind of an anti-pattern anyway, it’s absolutely full of this type of foot gun. Just use ansible or similar and build a new one.

or cloud-init

boot the clean base image and configure it on boot with packages, ssh keys, custom commands, etc.

Ansible has a non-trivial transition cost (speaking from experience here). Cloning VMs is a legitimate stopgap measure, because that’s sometimes the best you can do if available engineer hours are tight.

Ansible (as a proxy for infrastructure as code in general) being hard to implement is a warning that your setup is too convoluted. Cloning VMs is the high-interest unsecured loan of tech debt, and when that bill comes due it’s going to be much worse than spending a few days on some scripting.

Completely agree on all points, except for "few days". It took much longer than that, but partly due to learning Ansible as I went. The pain was still worth it, though.

Or better, cloud-init. It's same thing that cloud images to use to specialise VM "clones" to their environment, so is more likely to do all the right things. If it has a mechanism to detect that it's been cloned (eg. instance-id on EC2, etc) then it will deal with ssh key regeneration and everything else.

Reply on news.ycombinator.com