5.1How Virtual Machines Work and KVM

Running several independent OS instances on one physical server—virtualization—is core Linux infrastructure, from spinning up test environments to consolidating a data center. LinuC-2 centers on KVM, Linux's native hypervisor, and how it "fakes" CPU, memory, storage, and network resources for guests.

5.1.1Host-type vs hypervisor-type

• Host-type virtualization installs the hypervisor as an application on top of an existing OS (e.g., VirtualBox). Easy to set up, but the host OS adds overhead.
• Hypervisor-type virtualization controls hardware directly. On Linux, KVM runs as part of the kernel itself, giving each guest OS an isolated execution environment. Xen is a different approach with its own dedicated hypervisor layer.
• KVM (Kernel-based Virtual Machine) is a set of kernel modules that turn the Linux kernel itself into a hypervisor; guests are scheduled as ordinary Linux processes.

5.1.2Virtualizing CPU, memory, storage, and network

• CPU virtualization assigns virtual CPUs (vCPUs) to guests and relies on hardware virtualization extensions (vmx = Intel VT-x, svm = AMD-V) to handle privileged instructions efficiently. Check support via the flags field in /proc/cpuinfo or the Virtualization line in lscpu.
• Memory virtualization maps guest physical addresses to host physical addresses, making each guest appear to have its own independent memory space.
• Storage virtualization presents a virtual disk image file to the guest as its physical disk. Network virtualization connects host and guests through a virtual bridge/virtual NIC, configured with tools like bridge-utils.

KVM by itself is just a set of kernel modules (kvm plus the vendor-specific kvm-intel or kvm-amd) that use hardware virtualization support to virtualize the CPU and memory. Emulating devices—disks, network cards—is the job of QEMU, running in user space; it helps to remember the split as "KVM = the acceleration engine, QEMU = the device provider." The resident daemon that ties both together and manages a VM's lifecycle (create, start, stop, delete) is libvirtd, with the GUI tool virt-manager sitting on top. A typical setup checks for the vmx (Intel) or svm (AMD) flag via lscpu or cat /proc/cpuinfo, then confirms with lsmod | grep kvm that kvm_intel or kvm_amd is loaded. For networking, when a guest needs to participate transparently in the external network, the standard approach is to build a virtual bridge (e.g., br0) spanning the host's physical NIC with bridge-utils and attach the guest's virtual NIC to it—letting the guest behave as a first-class member of the physical LAN, unlike NAT-based setups.

5.1.3Section summary

• Host-type (VirtualBox) = app on existing OS / hypervisor-type (KVM, Xen) = direct hardware control
• KVM = kernel modules (kvm-intel/kvm-amd) accelerating CPU/memory, QEMU = device emulation; verify with vmx/svm in lscpu or /proc/cpuinfo