VM images, snapshots and networking

Why this matters

Building one server carefully and then stamping out fifty copies is the reason virtualisation took over. Doing it correctly is the difference between fifty working machines and fifty machines that share a host key and an SSH identity.

The networking half decides what a VM can reach and what can reach it, and choosing wrongly is why a guest has internet access but nothing on the LAN can connect to it.

The lesson

Templates and cloning

A baseline image template is a VM built once — patched, hardened, monitoring agent installed, standard accounts configured — then frozen and used as the origin for every new machine.

The essential step is generalising it before cloning. A clone of a running system carries identity that must not be duplicated:

virt-sysprep -d template-base

virt-sysprep removes SSH host keys, the machine ID, network interface persistence rules, logs, shell history, cron jobs and cached DHCP leases.

Skipping it is the classic mistake, and the symptoms are confusing. Fifty clones sharing an SSH host key means an attacker who takes one can impersonate all of them, and no client can tell. Fifty machines sharing /etc/machine-id means systemd journal identity collides and DHCP hands out the same address to different hosts, because many DHCP servers key on machine-id rather than MAC. Neither failure points at cloning as the cause.

virt-clone --original template-base --name web02 \
  --file /var/lib/libvirt/images/web02.qcow2

virsh dumpxml web01 > web01.xml        # export the definition
virsh define web01.xml                 # import it elsewhere

Linked clones use the template as a read-only backing file and store only differences, so fifty clones of a 20 GB template cost 20 GB plus deltas:

qemu-img create -f qcow2 -F qcow2 -b /images/base.qcow2 /images/web02.qcow2
qemu-img info /images/web02.qcow2      # shows the backing file

The trade is that the backing file must never change or be deleted. Modify it and every clone is corrupted at once. Keep templates read-only and version them rather than editing in place.

cloud-init is the modern alternative to cloning-then-editing: boot a generic image and let it configure hostname, users, SSH keys, packages and network from metadata supplied at first boot. One image, many configurations, no generalising step.

Snapshots

A snapshot preserves a VM's state so you can return to it.

virsh snapshot-create-as web01 before-upgrade "Before the 9.4 upgrade"
virsh snapshot-list web01
virsh snapshot-revert web01 before-upgrade
virsh snapshot-delete web01 before-upgrade

Internal snapshots live inside the qcow2 file. External ones create a new overlay and leave the original read-only, which performs better and is what production tooling uses.

Three things to be clear about, because they cause real losses:

A snapshot is not a backup. It lives on the same storage as the VM, usually in the same file. Lose the datastore and you lose both. Its purpose is a short undo for a risky change, not retention.

Snapshots degrade performance and grow without limit. Every write goes into the overlay chain, so a machine left snapshotted for months accumulates a long chain that slows reads and can eventually fill the datastore. Delete them when the change is confirmed good.

A snapshot of a running database may not be consistent unless memory state is included, or the application is quiesced first. --quiesce uses the guest agent to flush filesystems before the snapshot, and it is what makes the copy restorable.

Migrations

Migrations move a VM from one host to another, and come in two kinds.

Cold migration — shut the VM down, copy its disk and definition, start it elsewhere. Simple and always works.

Live migration moves a running VM between hosts with no perceptible downtime:

virsh migrate --live web01 qemu+ssh://host2/system
virsh migrate --live --persistent --undefinesource web01 qemu+ssh://host2/system

Memory pages are copied while the guest runs, then the remaining dirty pages and CPU state are transferred in a brief pause of milliseconds.

Its requirements are strict and are what usually block it: shared storage both hosts can reach (or --copy-storage-all, which is far slower), compatible CPUs — a guest cannot move to a host lacking instructions it is already using — and network connectivity between hypervisors. CPU incompatibility is why clusters define a lowest-common-denominator CPU model rather than host-passthrough, which trades a little performance for the ability to move machines at all.

Bare metal versus virtual

Virtualisation costs a few percent of performance and buys consolidation, snapshots, live migration, and hardware independence. Bare metal is still right for a few cases:

• Latency-sensitive work where a few percent and jitter matter
• Direct hardware access — GPUs, specialised cards — without passthrough
• Licensing that is priced per physical socket
• The hypervisor hosts themselves

The middle ground is worth knowing: containers share the host kernel and so have almost no overhead, but provide weaker isolation than a VM. Increasingly the answer is containers on VMs on bare metal, each layer chosen for what it gives.

Virtual networking

The network type decides reachability, and this is the part most often chosen wrongly.

NAT (libvirt's default network) — guests get addresses on a private virtual network and reach the outside through the host, which translates addresses. Outbound works; inbound does not without explicit port forwarding. The safe default for desktops and labs, and the reason a guest can browse the internet while nothing on the LAN can reach its web server.

Bridged — the guest attaches directly to the physical network and gets an address from the LAN's own DHCP, appearing as a peer of the physical machines. This is what servers want: other hosts connect to it normally.

# /etc/NetworkManager/system-connections/ or nmcli
nmcli connection add type bridge ifname br0
nmcli connection add type bridge-slave ifname eth0 master br0

Host-only / isolated — guests can talk to each other and, in host-only mode, to the host, but have no route outward. Correct for a test network of machines that must not reach production, or a database tier that only its application should reach.

Routed — guests are on their own subnet, and the host routes between it and the physical network without translating addresses. Inbound connections work (unlike NAT) and guests keep their own addresses (unlike bridged), but the upstream router needs a route to that subnet.

Open — libvirt creates the network but adds no firewall rules at all, leaving filtering entirely to you.

virsh net-list --all
virsh net-info default
virsh net-dumpxml default
virsh net-start default
virsh net-autostart default
virsh domiflist web01
virsh attach-interface web01 bridge br0 --model virtio --persistent

The short decision: bridged for servers, NAT for desktops and labs, isolated for anything that must not reach the network, routed when you want inbound without bridging.

Note --model virtio on that attach command — the same paravirtualised performance point from the previous lesson applies to network interfaces.

The tools

libvirt is the management layer: a daemon (libvirtd) and an API that abstracts KVM, Xen, LXC and others, so the same commands work across hypervisors. Domain definitions are XML.

virsh is its command-line client — everything above.

virt-manager is the graphical console. (The objectives list it as vit-manager, which is a typo in the published document; the package is virt-manager.) It gives a VM list, a graphical console, and wizards for creating machines — genuinely useful for installing an OS interactively, where virsh alone is awkward.

virsh edit web01                    # edit the domain XML
virsh dumpxml web01 | less
virsh domstate web01
virsh console web01                 # serial console — Ctrl-] to exit
virt-install --name web03 --memory 4096 --vcpus 2 \
  --disk size=40 --os-variant rhel9.0 --location <url> --graphics none

virsh console is the one to remember. When a VM has lost its network you cannot SSH to it — the console is the way in, and it works because it is a serial connection through the hypervisor rather than over the guest's network. It requires the guest to have a serial console enabled (console=ttyS0 on the kernel command line), which is worth putting in your template so it is there when you need it.

On the exam

• Generalise with virt-sysprep before cloning, or clones share SSH host keys and machine-id.
• Linked clones depend on a backing file that must never change.
• A snapshot is not a backup — same storage, and it degrades performance as the chain grows.
• Live migration needs shared storage and compatible CPUs; that CPU requirement is why clusters avoid host-passthrough.
• NAT allows outbound only; bridged puts the guest on the LAN. Servers want bridged. Isolated has no external route; routed gives inbound without bridging.
• virsh console reaches a VM whose network is broken.
• libvirt is the abstraction layer, virsh the CLI, virt-manager the GUI.
• Use --model virtio for network interfaces, as for disks.