Running Linux as a virtualization guest

Virtual machines and containers are not the same isolation

A virtual machine runs its own kernel on virtualized hardware, so it can be a completely different operating system from its host, and it pays for that with the overhead of a second kernel and a full boot. A container shares the host kernel and is isolated by namespaces and cgroups, so it starts in milliseconds and cannot run a different kernel or a different operating system family. Guest drivers — virtio disks and network cards, or the vendor's guest additions — exist to give a virtual machine near-native speed by letting it talk to the hypervisor directly rather than pretending to drive emulated hardware.

Guest integration comes in two layers that are easy to run together, and separating them is what the question is for. Paravirtualized drivers move DATA: virtio disks and network cards, and their equivalents on other platforms. A guest AGENT takes ORDERS — it is a daemon inside the guest listening on a channel to the hypervisor, and it does the things no driver can: accepting a request to shut down cleanly rather than having the virtual power cord pulled, freezing and then thawing the filesystems so a snapshot is taken at a consistent moment, and reporting the guest's addresses back to the host. Each platform ships its own: qemu-guest-agent for QEMU and KVM, open-vm-tools for VMware, hyperv-daemons for Hyper-V. Without one the host can still stop the machine; it simply cannot ask.

What must be unique after cloning

Cloning a prepared system image is the normal way to create guests, and the things that must not be duplicated are the ones the exam asks about. SSH host keys in /etc/ssh must be regenerated, or every clone presents the same identity and a client cannot tell them apart. The D-Bus machine id in /etc/machine-id must be reset, since systemd and the journal key on it. Network configuration must not pin a MAC address or a static IP inherited from the template, and the hostname has to be set.

cloud-init is the standard mechanism for doing exactly that at first boot: it reads metadata supplied by the cloud platform — hostname, SSH keys, users, an arbitrary user-data script — and applies it before the machine is handed over. That is why an image can be generic and the instance made from it specific.