Skip to content

VM Images and Cloning

A VM disk is a file in a format such as qcow2 or raw, and a template is an image cloned to make new VMs. Cloning safely means resetting the identifiers that must be unique per host, or clones collide on the network.

Track: Advanced · Interview weight: Low

Must-Know Facts

Fact Value Verify with
qcow2 QEMU copy-on-write: thin, snapshots, backing files qemu-img info disk.qcow2
raw Full flat file; fastest, no thin provisioning qemu-img info disk.raw
Convert Change format between qcow2 and raw qemu-img convert
virtio Paravirtual disk and network drivers, faster than emulated lspci in guest
Template A cleaned base image cloned for new VMs virt-clone, virt-sysprep
machine-id Must be unique per host; reset on clone cat /etc/machine-id
SSH host keys Must be unique per host; regenerate on clone ssh-keygen -A
virt-sysprep Cleans an image (logs, keys, machine-id) for templating virt-sysprep -a img

Disk Image Formats

qcow2 is thin: it grows as data is written rather than occupying the full virtual size, and supports snapshots and backing files. raw is a flat, always-full file that is faster. qemu-img creates and inspects them.

qemu-img create -f qcow2 vm.qcow2 10G
qemu-img info vm.qcow2 | grep -E 'file format|virtual size|disk size'

Output:

file format: qcow2
virtual size: 10 GiB (10737418240 bytes)
disk size: 196 KiB

The image presents 10 GiB to the guest but occupies 196 KiB on the host until data is written. qemu-img convert -O raw produces a full-size flat file where a platform requires raw.

Cloning and the Identifier Problem

A clone is a byte copy of the template, so it inherits the template's unique identifiers. Two must be reset or clones conflict: the machine-id and the SSH host keys.

cat /etc/machine-id
ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

Output:

df78a6d48a354e008feac96782e02615
256 SHA256:kqAhsu1+xTZAVKl06Q+WunnVuxGbn6kGqg609O49goM sshd@web (ED25519)

Shared machine-ids make DHCP and systemd treat clones as one host; shared host keys make clients unable to distinguish them and break host-key checks. The reset truncates the machine-id and deletes the host keys, both regenerated on next boot.

sudo truncate -s 0 /etc/machine-id       # regenerated on next boot
sudo rm -f /etc/ssh/ssh_host_*           # regenerated by ssh-keygen -A or on boot

Cloned VMs that share host keys or machine-id collide

Duplicate SSH host keys make two hosts indistinguishable and trip host-key verification; a shared machine-id breaks DHCP leases and systemd identity. Reset both, or let virt-sysprep do it.

virt-sysprep prepares an image to be a template

virt-sysprep -a image.qcow2 strips host-specific data (logs, machine-id, SSH host keys, history, cloud-init state) so the image boots as a fresh host. virt-clone then makes a new VM from it.

Common Errors

two cloned VMs get the same DHCP lease or IP

Cause: they share a machine-id (used as the DHCP client identifier) or a duplicated network config.

Fix: reset /etc/machine-id on the template before cloning, or run virt-sysprep.

WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED connecting to a new clone

Cause: the clone reused the template's SSH host keys, presenting keys clients know for another host.

Fix: regenerate host keys per clone (ssh-keygen -A after removing the old ones), which sysprep does.

Interview Checkpoints

L1: What is the difference between qcow2 and raw disk images?

Say first: qcow2 is thin and supports snapshots and backing files; raw is a flat full-size file that is faster with no thin provisioning.

Proof: qemu-img info shows qcow2's disk size far below its virtual size.

Follow-up: when would you convert qcow2 to raw? (when a platform requires raw, with qemu-img convert.)

L1: Which identifiers must be unique per host when cloning a VM?

Say first: the machine-id and the SSH host keys, at least.

Proof: /etc/machine-id and /etc/ssh/ssh_host_*_key; both must be regenerated on a clone.

Follow-up: what breaks if SSH host keys are shared? (clients cannot tell the hosts apart; host-key checks fail.)

L2: Prepare a VM image to be a reusable template.

Say first: clean host-specific data with virt-sysprep.

Proof: sudo virt-sysprep -a template.qcow2.

Follow-up: what does sysprep remove? (logs, machine-id, SSH host keys, history, cloud-init state.)

L3: New clones keep getting the same IP from DHCP. Diagnose it.

Say first: the clones share a machine-id, which many DHCP clients use as the client identifier, so the server hands them the same lease.

Proof: compare /etc/machine-id across clones; reset it on the template and re-clone.

Follow-up: what other identity does this affect? (systemd's per-host identity and journald.)

L2: Regenerate SSH host keys on a cloned host.

Say first: remove the old keys and generate fresh ones.

Proof: sudo rm -f /etc/ssh/ssh_host_*; sudo ssh-keygen -A.

Follow-up: how does this happen automatically? (cloud-init or the ssh service regenerates missing keys on boot.)

L2: A thin qcow2 disk is reported as full size on the host. What happened?

Say first: it was converted to raw or preallocated, so it now occupies the full virtual size.

Proof: qemu-img info shows disk size equal to virtual size; recreate as qcow2 for thin behaviour.

Follow-up: why use raw at all? (slightly faster, and required by some platforms.)

Captured on Rocky Linux 10.2 on an iximiuz Labs FlexBox microVM, kernel 6.1.167, 2026-09. virt-sysprep and virt-clone need a libvirt host and are shown without output.