Virtualizzazione — Cheat Sheet

Tags: virtualization, hypervisor, kvm, vmware, qemu, containers, sysadmin, devops

Level: intermediate

TL;DR: Virtualization abstracts physical hardware via hypervisors (Type 1 bare-metal, Type 2 hosted) to run isolated guest operating systems with dedicated virtual resources.

Key concepts

Type 1 hypervisors run directly on bare metal (e.g., ESXi, Proxmox, Xen, KVM) with low overhead.

Type 2 hypervisors run on top of an existing host OS (e.g., VirtualBox, VMware Workstation).

Hardware-assisted virtualization relies on CPU extensions (Intel VT-x, AMD-V) to execute guest code efficiently.

Full virtualization emulates complete hardware, requiring no modifications to guest operating systems.

Paravirtualization requires guest OS awareness with optimized drivers (e.g., VirtIO) to bypass hardware emulation.

Virtual machines isolate guest OS kernels entirely, unlike containers which share the host kernel.

CPU overcommit schedules multiple vCPUs per physical core, managed dynamically by hypervisor schedulers.

Memory ballooning reclaims idle RAM from guest VMs to dynamically allocate it to overloaded guests.

Live migration transfers running VMs between physical hosts with minimal latency and zero downtime.

Virtual disks use thin provisioning to allocate physical space on demand rather than pre-allocating full capacity.

Typical questions and ready answers

Q: What is the primary difference between a Type 1 and a Type 2 hypervisor?R: Type 1 runs directly on bare metal without an intermediate OS, giving higher performance and direct device control. Type 2 runs inside a standard host OS, making it easier for desktop testing but adding performance overhead.

Q: How do containers differ from traditional virtual machines?R: VMs virtualize hardware and run complete, independent guest OS kernels. Containers share the host kernel and isolate processes via namespaces and cgroups, making containers lighter, faster to boot, and less resource-heavy.

Q: What role does VirtIO play in Linux KVM environments?R: VirtIO provides standardized paravirtualized device drivers for storage and networking, eliminating hardware emulation overhead and significantly increasing I/O throughput between host and guest.

Pitfalls and common mistakes

Overcommitting physical CPU cores excessively, leading to severe vCPU scheduling latency and guest stalls.

Ignoring snapshot lifecycles; long-running snapshots inflate disk usage and cause severe storage I/O degradation.

Using thick-provisioned storage everywhere without planning capacity, wasting costly SAN/NAS storage.

Disabling hardware virtualization (VT-x/AMD-V) in BIOS/UEFI, which forces hypervisors into slow software emulation.

Running time-sensitive applications without proper NTP/PTP synchronization between hypervisor host and guest clocks.

Snippets and commands

# Verify hardware virtualization support on Linux
egrep -c '(vmx|svm)' /proc/cpuinfo

# List active virtual machines using libvirt
virsh list --all

# Inspect CPU and memory resource usage of running guests
virt-top

# Create a qcow2 virtual disk with thin provisioning (20GB max)
qemu-img create -f qcow2 disk_image.qcow2 20G

# Check information and actual allocated size of a virtual disk
qemu-img info disk_image.qcow2

To review

[ ] Memory ballooning mechanics and KSM (Kernel Samepage Merging) behavior

[ ] SR-IOV (Single Root I/O Virtualization) configuration for high-throughput networking

[ ] VirtIO storage drivers versus emulated SATA/SCSI performance profiles

[ ] Live migration prerequisites and shared storage backends (NFS, iSCSI, Ceph)

[x] Differences between Type 1 and Type 2 hypervisors