KVM on Linux
Linux KVM is the virtualization module built into the Linux Kernel, which turns one physical host into multiple isolated guest machines, each with its own kernel, memory, and network.
It ships as a set of kernel modules, and on a 16 GB host you can run 4 guest stacks with 4 GB of RAM each and leave 0 headroom for nothing. KVM was upstreamed in 2007, merged into the mainline kernel as version 2.6.20, and has carried the KVM acronym ever since. As a hypervisor it is Type 1, because the host kernel schedules guest virtual machines directly on hardware virtualization extensions such as Intel VT-x and AMD-V. The practical consequence for a web administrator is that each LAMP guest runs in its own isolated address space, so a misconfigured PHP worker or a runaway cron job in one guest cannot exhaust the memory of another.
How KVM Virtualizes the Host
To see how KVM virtualizes the host, start with the two pieces of hardware it relies on: the VT-x instruction set on Intel CPUs and the AMD-V feature on AMD CPUs. Before these extensions, software emulated the CPU instruction by instruction, which made each guest run at roughly 10 to 30 percent of native speed. With hardware assistance, a guest executes most instructions directly on the physical core and only traps to the host kernel on privileged operations. The KVM module installs itself as /dev/kvm, and the userspace program that drives each guest is QEMU, which creates the virtual disks, virtual network cards, and the console you see. That split is the whole design: the Linux Kernel owns the scheduling and memory isolation, and QEMU owns the emulation of the remaining devices. The result is that a KVM guest performs within a few percent of bare metal, a figure you can confirm with any disk or CPU benchmark.
Setting Up KVM for Staging
Set up KVM for staging by installing the kvm and qemu-kvm packages, enabling the KVM module, and creating a guest image, all of which takes about 15 minutes on a current distro. The steps below run on an RHEL 9 or Debian 12 host, and you work through them as the root user with a normal terminal session.
- Install the stack with dnf install kvm qemu-kvm libvirt virt-install on RHEL, or apt install qemu-kvm libvirt-daemon-system on Debian.
- Load the module and confirm the host sees it with lsmod | grep kvm, which should list the kvm and kvm_intel or kvm_amd lines.
- Check that the CPU exposes virtualization with egrep -c '(vmx|svm)' /proc/cpuflags, which prints a count of the supporting cores.
- Create a 20 GB virtual disk with qemu-img create -f qcow2 lamp-staging.qcow2 20G.
- Launch the guest with virt-install, assigning it 2 CPU cores and 4 GB of RAM so the LAMP stack inside stays comfortably within the host budget.
Those Linux Commands are short enough to memorize, and each one maps to a single object you can inspect afterward: the module, the flag, the image file, and the running guest. Working through them in order means that if a later step fails, you know exactly which of the earlier 4 did not take effect. The guest boots into its own Linux Kernel, so staging becomes a true reproduction of production rather than a container sharing the host kernel. Once it is up, the guest is where the day to day administration of the LAMP stack happens, and you can reach it over the network with ssh, exactly as you would a dedicated server.
Choosing Guest Sizing
Size the guest to the workload, and a staging LAMP box is the case where a 4 GB allocation covers Apache, MariaDB, and PHP with headroom for a 200 concurrent request load. The sizing follows the same rule you would apply to a real server. If production runs Apache with 10 worker processes, MariaDB with an 800 MB buffer pool, and PHP with 5 FPM processes, the staging guest needs enough RAM for all three plus a margin for page cache, and 4 GB is a figure that fits that sum without waste.
Tuning Memory, CPU, and I/O
Tune memory, CPU, and I/O by setting the guest resources first and then checking the host does not oversubscribe, because oversubscription is where staging silently goes wrong. The three levers you turn are the guest RAM size, the number of vCPUs, and the disk image format, and the table below shows what each one costs on the host.
| Setting | Value | What it costs the host |
|---|---|---|
| Guest RAM | 4 GB per guest | 4 GB reserved, plus page cache on top |
| vCPUs | 2 per guest | 2 host threads, schedulable against other guests |
| Disk image | 20 GB qcow2 | Sparsely allocated, grows as the guest writes |
Use the qcow2 format rather than raw, because qcow2 allocates blocks only when the guest writes them and supports snapshots that you can revert after a botched Apache config change. On a 16 GB host, 4 guests at 4 GB each leave the host kernel and the host userspace with 0 GB of guaranteed free RAM, which is why the rule is to keep total guest RAM below about 75 percent of physical memory. The remaining 25 percent, roughly 4 GB here, is the headroom that keeps the host from swapping when two guests spike at once.
Hardening a LAMP Guest
Harden a LAMP guest by closing the 3 attack surfaces that matter most on a staging box: the web server, the database, and the remote shell. Because staging sits on a network reachable by the team, it deserves the same care as production, and the work fits in a 1 hour pass. The first move is to run the web server user without root, which Apache already does, and to bind MariaDB to 127.0.0.1 so it answers only the local host instead of every interface. The second is to move phpMyAdmin or any admin panel behind a firewall rule that allows only the admin subnet. The third is to disable password login in the guest and use SSH keys, which removes the 1 brute-force vector that most staging boxes are left exposed to. For the file side of things, the staging root is a plain directory tree, so when a test deploys a file to the wrong path, the way to locate it is to use a Find Files on Linux search with locate or find, and both return the path in a couple of seconds on a 20 GB image. That same search habit is what makes the Linux for the LAMP stack pages a natural next read, since they cover the server-side stack from the other direction: the same Apache, MariaDB, and PHP that the guest is running, described as the production configuration rather than the staging copy. Hardening the guest and reading the stack guide together close the loop between the virtual machine and the software inside it.
Running and Verifying the Stack
Run and verify the stack by booting the guest, confirming the services are up, and pointing a browser at the host IP with the guest port, and a healthy box answers on the first request. Inside the guest, systemctl status apache, systemctl status mariadb, and systemctl status php-fpm should each report active and running, and the 3 units together are the whole LAMP stack on that machine. The network check is to curl the guest from the host and read back the default Apache page, which proves that the virtual NIC, the routing, and the web server are all working as a chain. Because the guest runs its own kernel, a crash inside the guest is isolated and recoverable: you reboot that one virtual machine with virsh reboot, and the other guests on the host never notice. That isolation is the reason to stage in KVM at all, and it is what separates it from sharing one kernel across a fleet of containers.