Linux+ Cloud and Virtualization: KVM/libvirt, cloud-init, and Hybrid Operation

For decades, a server was a pet. You named it apollo, you logged in over months to hand-tune its config, and when it got sick you nursed it back to health because nobody remembered exactly how it was built. That works until apollo dies at 3 a.m. and you have no way to rebuild it.

The cloud-era model is cattle. Each instance is one of an interchangeable herd: it's described entirely by an image plus a definition file (infrastructure-as-code), so if one misbehaves you don't nurse it — you destroy it and stamp out an identical replacement from the same recipe.

This lesson is the toolset that makes cattle possible on Linux: KVM/libvirt to run virtual machines, cloud-init to provision them automatically on first boot, and instance metadata to feed each one its identity and secrets at runtime.

Linux virtualization is a layered stack, and the exam expects you to know which layer does what:

• KVM (Kernel-based Virtual Machine) is a module inside the Linux kernel that turns the kernel itself into a Type-1 (bare-metal) hypervisor — guest VMs run directly on the hardware's CPU virtualization extensions, not on top of a host OS.
• QEMU emulates the virtual hardware each guest sees (disk, network card, display).
• libvirt is the management layer — a stable API and daemon (libvirtd) that sits in front of KVM/QEMU so you have one consistent toolset regardless of the hypervisor underneath.
• `virsh` is the command-line client you type at, and `virt-install` is the tool that builds a brand-new VM.

Think of it like an airport: KVM is the runway and control tower built into the ground itself, QEMU is the individual aircraft, and libvirt is the booking-and-dispatch system you actually interact with — you never talk to the runway directly.

virsh is to VMs what systemctl is to services: a single command with a verb set you learn once. Start by looking before you touch — list what exists and its state.

virsh manages VMs that already exist; `virt-install` stamps out new ones. It defines the virtual hardware and points the guest at an OS source so it can boot and install.

But should this even be a VM? A VM carries its own full kernel and OS, which is heavy. A container shares the host's kernel and ships only the app and its libraries, which is light. The choice is a single trade-off:

• VM → isolation. Its own kernel means a compromised or crashing guest can't easily reach the host or its neighbours. Pick a VM for hostile multi-tenant workloads, for a different OS/kernel than the host, or when strong security boundaries are required.
• Container → density. Sharing the kernel means near-zero overhead, so you pack far more workloads per host and they start in milliseconds. Pick a container for many instances of your own stateless services.

A freshly stamped image is generic and identical to every other copy. cloud-init is what turns that generic image into this specific instance — and it does it automatically on the instance's very first boot.

On that first boot cloud-init reads user-data (a config you supply, usually YAML) and applies it: it sets the hostname, creates users, installs their SSH keys, installs packages, writes files, and runs arbitrary scripts. Think of it as the instance's new-hire onboarding: the laptop comes off the shelf identical for everyone, and onboarding personalizes it — accounts, access badges, software — on day one.

How does cloud-init know it should be web02 and not web57? It asks the platform, not the image. Every cloud (and many on-prem setups) exposes an instance metadata service at a fixed link-local address: `169.254.169.254`. Link-local means it's only reachable from the instance itself and never routes off the box — so it's a private channel between the running instance and the platform.

The instance queries that endpoint at boot to learn who it is — its hostname, its user-data, and short-lived credentials the platform mints for it. The principle: identity and secrets come FROM the platform AT runtime; they are never baked into the image.

You have a real root shell. These are read-only probes — they only report what's present, they change nothing. Run them in order to see which parts of the stack this box has. It's fine if a tool isn't installed; the || echo fallback just tells you so instead of erroring.