Part 4: Virtualization Deep Dive

Introduction

Virtualization is the foundational technology that made cloud computing possible. Before virtualization, every application required its own dedicated physical server — leading to massive hardware waste, complex provisioning, and months-long deployment cycles. Virtualization changed everything by allowing multiple isolated operating systems to share a single physical machine.

Why Virtualization Matters

Consider a typical enterprise data center before virtualization:

• Server utilization: 5-15% on average — each application owned an entire machine
• Provisioning time: 6-12 weeks to procure, rack, and configure new servers
• Power & cooling: Massive costs for servers mostly sitting idle
• Disaster recovery: Required duplicate hardware at secondary sites

With virtualization, those same servers now run at 60-80% utilization, new VMs provision in minutes, and disaster recovery becomes a matter of copying virtual disk files.

                                flowchart LR
                                    A[Physical Server
5-15% utilized] -->|Virtualization| B[Same Server
60-80% utilized]
                                    B --> C[VM 1: Web Server]
                                    B --> D[VM 2: Database]
                                    B --> E[VM 3: App Server]
                                    B --> F[VM 4: Dev/Test]
                            

Hypervisor Types

A hypervisor (also called a Virtual Machine Monitor or VMM) is the software layer that creates and manages virtual machines. There are two fundamental categories, each with distinct architectures and use cases.

Type 1 Hypervisors (Bare Metal)

Type 1 hypervisors run directly on the physical hardware with no underlying operating system. They provide the thinnest possible abstraction layer, delivering near-native performance for guest VMs.

                                flowchart TB
                                    subgraph Hardware["Physical Hardware"]
                                        CPU["CPU (VT-x/AMD-V)"]
                                        RAM["RAM"]
                                        NIC["Network Card"]
                                        DISK["Storage"]
                                    end
                                    subgraph Hypervisor["Type 1 Hypervisor (ESXi / KVM / Hyper-V)"]
                                        SCHED["CPU Scheduler"]
                                        MEM["Memory Manager"]
                                        IO["I/O Manager"]
                                    end
                                    subgraph VMs["Virtual Machines"]
                                        VM1["VM 1
Linux + App"]
                                        VM2["VM 2
Windows + SQL"]
                                        VM3["VM 3
Linux + Docker"]
                                    end
                                    Hardware --> Hypervisor
                                    Hypervisor --> VMs
                            

VMware ESXi

VMware ESXi is the industry-dominant enterprise hypervisor. It's a purpose-built microkernel that boots directly on hardware, with a footprint of approximately 150 MB. ESXi provides the foundation for VMware's vSphere platform, which adds centralized management, vMotion live migration, DRS (Distributed Resource Scheduler), and HA (High Availability).

# Check ESXi version and build on an ESXi host
esxcli system version get

# List all VMs on the host
vim-cmd vmsvc/getallvms

# Get VM power state
vim-cmd vmsvc/power.getstate 1

# Show CPU and memory allocation
esxcli hardware cpu global get
esxcli hardware memory get

# List virtual switches
esxcli network vswitch standard list

KVM (Kernel-based Virtual Machine)

KVM turns the Linux kernel itself into a hypervisor. When the KVM kernel module loads, Linux gains the ability to act as a Type 1 hypervisor while retaining all standard Linux functionality. Each VM runs as a standard Linux process, managed by QEMU for device emulation.

# Check if hardware virtualization is supported
grep -Ec '(vmx|svm)' /proc/cpuinfo

# Install KVM on Ubuntu/Debian
sudo apt update
sudo apt install -y qemu-kvm libvirt-daemon-system libvirt-clients bridge-utils virt-manager

# Verify KVM is loaded
lsmod | grep kvm

# List running VMs
virsh list --all

# Get VM info
virsh dominfo my-vm

# Show vCPU mapping to physical cores
virsh vcpuinfo my-vm

Microsoft Hyper-V

Hyper-V uses a "micro-kernelized" architecture where both the management OS (root partition) and guest VMs are peers on top of the hypervisor. The root partition has privileged access for hardware management, but the hypervisor is the true bare-metal layer.

# PowerShell: Check Hyper-V status
Get-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V

# List all VMs
Get-VM

# Get VM details
Get-VM -Name "MyVM" | Select-Object *

# Show VM processor configuration
Get-VMProcessor -VMName "MyVM"

# Show VM memory configuration
Get-VMMemory -VMName "MyVM"

Xen

Xen is an open-source hypervisor originally developed at Cambridge University. It pioneered paravirtualization and is the foundation of AWS's original EC2 infrastructure. Xen uses a privileged domain (Dom0) for hardware management and unprivileged domains (DomU) for guest VMs.

# List all Xen domains
xl list

# Get domain info
xl info

# Show vCPU to physical CPU mapping
xl vcpu-list

# Display memory allocation across domains
xl mem-list

# Show Xen version and capabilities
xm info | grep -E "xen_version|hw_caps"

Type 2 Hypervisors (Hosted)

Type 2 hypervisors run as applications on top of an existing operating system. They're ideal for development, testing, and learning but carry additional overhead since they must pass through the host OS for hardware access.

                                flowchart TB
                                    subgraph Hardware["Physical Hardware"]
                                        HW["CPU + RAM + Disk + NIC"]
                                    end
                                    subgraph HostOS["Host Operating System (Windows/macOS/Linux)"]
                                        KERN["Host Kernel"]
                                        APPS["Host Applications"]
                                    end
                                    subgraph T2["Type 2 Hypervisor (VirtualBox/VMware Workstation)"]
                                        ENG["Virtualization Engine"]
                                    end
                                    subgraph GuestVMs["Guest VMs"]
                                        G1["Guest VM 1"]
                                        G2["Guest VM 2"]
                                    end
                                    Hardware --> HostOS
                                    HostOS --> T2
                                    T2 --> GuestVMs
                            

# VirtualBox: List all registered VMs
VBoxManage list vms

# Create a new VM
VBoxManage createvm --name "ubuntu-server" --ostype Ubuntu_64 --register

# Modify VM settings
VBoxManage modifyvm "ubuntu-server" --cpus 2 --memory 4096 --vram 32

# Create and attach a virtual disk
VBoxManage createmedium disk --filename ~/VMs/ubuntu-server.vdi --size 40960
VBoxManage storageattach "ubuntu-server" --storagectl "SATA" \
    --port 0 --device 0 --type hdd --medium ~/VMs/ubuntu-server.vdi

# Start VM headless
VBoxManage startvm "ubuntu-server" --type headless

# Show VM info
VBoxManage showvminfo "ubuntu-server"

Type 1 vs Type 2 Comparison

Virtual Machine Architecture

A virtual machine is a complete emulated computer system. The hypervisor presents virtualized versions of all hardware components: CPU, memory, disk controllers, network adapters, USB ports, and more. The guest OS inside the VM believes it's running on real hardware.

                                flowchart TB
                                    subgraph VM["Virtual Machine"]
                                        APP["Application Layer
(nginx, MySQL, custom apps)"]
                                        LIBS["Libraries & Runtime
(libc, Python, Java)"]
                                        GUEST["Guest Operating System
(Linux kernel / Windows)"]
                                        VHARDWARE["Virtual Hardware
(vCPU, vRAM, vNIC, vDisk)"]
                                    end
                                    subgraph HV["Hypervisor Layer"]
                                        TRAP["Trap & Emulate / VT-x"]
                                        SCHED2["CPU Scheduler"]
                                        MEMMGR["Memory Manager (EPT/NPT)"]
                                        IOMGR["I/O Virtualization"]
                                    end
                                    subgraph PHY["Physical Hardware"]
                                        PCPU["Physical CPUs"]
                                        PRAM["Physical RAM"]
                                        PNIC["Physical NICs"]
                                        PDISK["Physical Storage"]
                                    end
                                    APP --> LIBS
                                    LIBS --> GUEST
                                    GUEST --> VHARDWARE
                                    VHARDWARE --> HV
                                    HV --> PHY
                            

VM Lifecycle

# KVM/libvirt: Complete VM lifecycle demonstration

# Create a VM from an ISO
virt-install \
    --name web-server \
    --ram 4096 \
    --vcpus 2 \
    --disk path=/var/lib/libvirt/images/web-server.qcow2,size=40 \
    --os-variant ubuntu22.04 \
    --network bridge=br0 \
    --cdrom /var/lib/libvirt/isos/ubuntu-22.04-server.iso \
    --graphics vnc

# Check VM state
virsh domstate web-server

# Pause and resume a VM
virsh suspend web-server
virsh resume web-server

# Take a snapshot
virsh snapshot-create-as web-server --name "pre-upgrade" --description "Before kernel upgrade"

# List snapshots
virsh snapshot-list web-server

# Revert to snapshot
virsh snapshot-revert web-server pre-upgrade

# Shutdown and destroy
virsh shutdown web-server
virsh destroy web-server       # Force power off
virsh undefine web-server      # Remove definition

Virtual CPUs (vCPUs)

A virtual CPU is the hypervisor's abstraction of a physical CPU core. When a guest OS executes instructions, the hypervisor schedules those operations on actual physical cores. Understanding vCPU mapping is critical for performance tuning.

vCPU Scheduling

The hypervisor scheduler determines which vCPU runs on which physical core and for how long. This is analogous to OS process scheduling, but with an additional layer of complexity since each vCPU may itself be scheduling processes internally.

                                flowchart LR
                                    subgraph VMs["Virtual Machines"]
                                        VM1_V1["VM1 vCPU0"]
                                        VM1_V2["VM1 vCPU1"]
                                        VM2_V1["VM2 vCPU0"]
                                        VM2_V2["VM2 vCPU1"]
                                        VM2_V3["VM2 vCPU2"]
                                        VM3_V1["VM3 vCPU0"]
                                    end
                                    subgraph Scheduler["Hypervisor CPU Scheduler"]
                                        S["Time-slice allocation"]
                                    end
                                    subgraph Physical["Physical Cores"]
                                        C0["Core 0"]
                                        C1["Core 1"]
                                        C2["Core 2"]
                                        C3["Core 3"]
                                    end
                                    VMs --> Scheduler
                                    Scheduler --> Physical
                            

# Check vCPU to physical CPU mapping on KVM
virsh vcpuinfo web-server

# Output example:
# VCPU:           0
# CPU:            3       (running on physical core 3)
# State:          running
# CPU time:       24.5s
# CPU Affinity:   yyyy    (allowed on all 4 cores)

# Show host CPU topology
lscpu | grep -E "^(CPU|Core|Socket|Thread)"

# Monitor vCPU utilization in real-time
virt-top

# Check overcommit ratio
echo "Physical cores: $(nproc)"
echo "Total vCPUs allocated: $(virsh list --all | awk 'NR>2 && NF>0 {print $2}' | \
    xargs -I{} virsh vcpucount {} --maximum | paste -sd+ | bc)"

CPU Pinning (Affinity)

CPU pinning binds specific vCPUs to specific physical cores, preventing the scheduler from migrating them. This eliminates cache thrashing and is essential for latency-sensitive workloads.

# Pin vCPU 0 of 'db-server' to physical core 2
virsh vcpupin db-server 0 2

# Pin vCPU 1 to physical core 3
virsh vcpupin db-server 1 3

# Verify pinning
virsh vcpupin db-server
# Output:
# VCPU   CPU Affinity
# 0      2
# 1      3

# XML-based persistent pinning (add to VM definition)
virsh edit db-server
# Add inside  section:
# 
#   
#   
# 

Virtual Memory Management

Memory virtualization adds a second layer of address translation. The guest OS manages its own virtual-to-physical page tables, but those "physical" addresses are actually guest physical addresses that the hypervisor must translate to true host physical addresses.

Memory Overcommit

Memory overcommit allows allocating more virtual memory to VMs than physically exists on the host. This works because most VMs don't use 100% of their allocated memory simultaneously.

# Check host memory usage and overcommit status
free -h

# Show KVM memory allocation per VM
virsh list --all | awk 'NR>2 && NF>0 {print $2}' | while read vm; do
    echo -n "$vm: "
    virsh dominfo "$vm" 2>/dev/null | grep "Max memory\|Used memory"
done

# Calculate memory overcommit ratio
TOTAL_PHYSICAL=$(free -m | awk '/^Mem:/{print $2}')
TOTAL_ALLOCATED=$(virsh list --all | awk 'NR>2 && NF>0 {print $2}' | \
    xargs -I{} virsh dominfo {} 2>/dev/null | \
    grep "Max memory" | awk '{sum+=$3} END{print sum/1024}')
echo "Physical: ${TOTAL_PHYSICAL}MB, Allocated: ${TOTAL_ALLOCATED}MB"
echo "Overcommit ratio: $(echo "scale=2; $TOTAL_ALLOCATED/$TOTAL_PHYSICAL" | bc):1"

# Check KSM (Kernel Same-page Merging) status - deduplicates identical pages
cat /sys/kernel/mm/ksm/pages_shared
cat /sys/kernel/mm/ksm/pages_sharing

Memory Ballooning

Ballooning is a cooperative memory management technique. A balloon driver inside the guest VM communicates with the hypervisor. When the host needs memory back, it inflates the balloon — the guest OS sees reduced available memory and starts paging internally, freeing physical pages the hypervisor can reallocate.

                                sequenceDiagram
                                    participant Host as Hypervisor
                                    participant Balloon as Balloon Driver (Guest)
                                    participant Guest as Guest OS
                                    Host->>Balloon: Inflate balloon (reclaim 2GB)
                                    Balloon->>Guest: Allocate 2GB inside guest
                                    Guest->>Guest: Page out less-used data
                                    Balloon->>Host: Return freed physical pages
                                    Host->>Host: Redistribute to other VMs
                                    Note over Host,Guest: Later, when pressure eases...
                                    Host->>Balloon: Deflate balloon (return 1GB)
                                    Balloon->>Guest: Free internal allocation
                                    Guest->>Guest: 1GB available again
                            

# Check balloon driver status inside a KVM guest
lsmod | grep virtio_balloon

# View current balloon size (from host perspective)
virsh dommemstat web-server
# Output includes:
# actual 4194304       (4GB allocated)
# swap_in 0
# swap_out 0
# available 4045224    (usable by guest)
# usable 2891736       (free in guest)
# balloon 0            (currently inflated by 0)

# Manually set balloon target (reduce guest to 3GB)
virsh setmem web-server 3145728 --live

# Restore to full allocation
virsh setmem web-server 4194304 --live

Transparent Huge Pages (THP)

Standard memory pages are 4KB. For VMs with large memory footprints, this means millions of page table entries and frequent TLB (Translation Lookaside Buffer) misses. Huge pages (2MB or 1GB) dramatically reduce TLB pressure.

# Check THP status on the host
cat /sys/kernel/mm/transparent_hugepage/enabled
# [always] madvise never

# Check available huge pages
grep -i huge /proc/meminfo
# HugePages_Total:     512
# HugePages_Free:      480
# HugePages_Rsvd:       32
# Hugepagesize:       2048 kB

# Allocate 1024 huge pages (2GB total)
echo 1024 | sudo tee /proc/sys/vm/nr_hugepages

# Make persistent across reboots
echo "vm.nr_hugepages = 1024" | sudo tee -a /etc/sysctl.conf

# Configure a KVM VM to use huge pages (in XML definition)
# 
#   
# 

# Verify VM is using huge pages
grep -c "^HugePages" /proc/$(pgrep -f "qemu.*web-server")/smaps | head -5

Virtual Networking

Virtual networking provides software-defined network connectivity between VMs, between VMs and physical networks, and between VMs across hosts. The virtual switch (vSwitch) is the cornerstone of VM networking.

Virtual Switches

                                flowchart TB
                                    subgraph Host["Physical Host"]
                                        subgraph VMs2["Virtual Machines"]
                                            VM_A["VM A
vNIC: 10.0.1.10"]
                                            VM_B["VM B
vNIC: 10.0.1.11"]
                                            VM_C["VM C
vNIC: 10.0.2.10"]
                                        end
                                        subgraph vSwitch["Virtual Switch (Open vSwitch)"]
                                            PORT1["Port Group: Production
VLAN 100"]
                                            PORT2["Port Group: Development
VLAN 200"]
                                        end
                                        PNIC["Physical NIC (uplink)"]
                                    end
                                    PHYNET["Physical Network / Router"]
                                    VM_A --> PORT1
                                    VM_B --> PORT1
                                    VM_C --> PORT2
                                    PORT1 --> PNIC
                                    PORT2 --> PNIC
                                    PNIC --> PHYNET
                            

# Open vSwitch: Create a virtual switch
sudo ovs-vsctl add-br br-int

# Add a port connected to physical NIC (uplink)
sudo ovs-vsctl add-port br-int eth0

# Create VLAN-tagged port groups
sudo ovs-vsctl add-port br-int vnet0 tag=100  # Production VLAN
sudo ovs-vsctl add-port br-int vnet1 tag=200  # Dev VLAN

# Show switch configuration
sudo ovs-vsctl show

# Show port statistics
sudo ovs-ofctl dump-ports br-int

# Linux bridge alternative: Create a bridge
sudo ip link add br0 type bridge
sudo ip link set br0 up
sudo ip link set eth0 master br0

# Attach VM interface to bridge
sudo ip link set vnet0 master br0

# Show bridge details
bridge link show

SR-IOV (Single Root I/O Virtualization)

SR-IOV is a hardware standard that allows a single physical NIC to present multiple virtual functions (VFs) directly to VMs, bypassing the hypervisor for data-plane operations. This achieves near-native network performance.

# Check SR-IOV support on the NIC
lspci -v | grep -A5 "Ethernet" | grep "SR-IOV"

# Enable SR-IOV virtual functions
echo 8 | sudo tee /sys/class/net/ens3f0/device/sriov_numvfs

# List created VFs
ip link show ens3f0
# Output shows VF entries with MAC addresses

# Assign a VF to a VM (via libvirt XML)
# 
#   
#     

#   
# 

# Verify VF assignment inside the VM
lspci | grep -i ethernet
ethtool -i ens3

Virtual Storage

Virtual storage abstracts physical disk into virtual disk images that can be easily managed, moved, and optimized independently of the underlying hardware.

Thin Provisioning

Thin provisioning allocates storage on-demand rather than pre-allocating the full size. A 100GB virtual disk might only consume 15GB on the host until the guest actually writes data.

# Create a thin-provisioned qcow2 disk (100GB logical, near-zero initial)
qemu-img create -f qcow2 /var/lib/libvirt/images/db-server.qcow2 100G

# Check actual size vs logical size
qemu-img info /var/lib/libvirt/images/db-server.qcow2
# virtual size: 100 GiB
# disk size: 196 KiB    <-- actual space used

# Monitor thin disk growth
du -h /var/lib/libvirt/images/db-server.qcow2
ls -lh /var/lib/libvirt/images/db-server.qcow2

# Convert thick (raw) to thin (qcow2)
qemu-img convert -f raw -O qcow2 thick-disk.raw thin-disk.qcow2

# Pre-allocate a thick disk (for performance-critical workloads)
qemu-img create -f qcow2 -o preallocation=full /var/lib/libvirt/images/fast.qcow2 50G

Snapshots & Live Migration

Snapshots capture the complete state of a VM (memory + disk) at a point in time. Live migration moves a running VM between physical hosts without downtime.

# Create a disk-only snapshot
virsh snapshot-create-as web-server \
    --name "before-upgrade-2026-05" \
    --description "Before kernel 6.8 upgrade" \
    --disk-only

# Create a full snapshot (memory + disk)
virsh snapshot-create-as web-server \
    --name "full-state-backup" \
    --description "Complete state capture"

# List and inspect snapshots
virsh snapshot-list web-server
virsh snapshot-info web-server "before-upgrade-2026-05"

# Revert to a snapshot
virsh snapshot-revert web-server "before-upgrade-2026-05"

# Delete a snapshot
virsh snapshot-delete web-server "before-upgrade-2026-05"

# Live migration (move running VM to another host)
virsh migrate --live --persistent --undefinesource \
    web-server \
    qemu+ssh://target-host/system \
    --migrateuri tcp://target-host:49152

# Monitor migration progress
virsh domjobinfo web-server

Cloud Virtualization

Major cloud providers have moved beyond generic hypervisors, building custom hardware and software stacks to maximize performance, security, and density at planet-scale.

AWS Nitro System

AWS Nitro is a complete re-architecture of the virtualization stack. Instead of a software hypervisor handling networking, storage, and security, dedicated hardware cards offload these functions, leaving virtually 100% of host resources for customer workloads.

                                flowchart TB
                                    subgraph NitroCards["Nitro Hardware Cards"]
                                        NC["Nitro Card
(Network I/O)"]
                                        SC["Nitro Card
(EBS Storage)"]
                                        SEC["Nitro Security Chip
(Hardware root of trust)"]
                                    end
                                    subgraph NitroHV["Nitro Hypervisor (Lightweight KVM)"]
                                        HV2["Minimal VMM
~zero overhead"]
                                    end
                                    subgraph Instances["EC2 Instances"]
                                        I1["Customer Instance 1
(full CPU access)"]
                                        I2["Customer Instance 2
(full CPU access)"]
                                    end
                                    NitroCards --> NitroHV
                                    NitroHV --> Instances
                            

Azure Hypervisor

Microsoft Azure uses a custom hypervisor derived from Hyper-V, optimized for cloud-scale operations. It features hardware-based isolation (AMD SEV-SNP for confidential computing) and a fleet management system handling millions of VMs.

# Azure CLI: Check VM SKU capabilities (including virtualization features)
az vm list-skus --location eastus --size Standard_D --output table

# Show VM instance metadata (from inside an Azure VM)
curl -s -H "Metadata:true" \
    "http://169.254.169.254/metadata/instance?api-version=2023-07-01" | \
    python3 -m json.tool

# Check if VM supports nested virtualization
az vm show --name myVM --resource-group myRG --query "hardwareProfile.vmSize"

# Azure accelerated networking (SR-IOV equivalent)
az network nic update --name myNIC --resource-group myRG --accelerated-networking true

GCP Titanium

Google Cloud Platform's Titanium offload system follows a similar philosophy to AWS Nitro, using custom ASICs to handle networking (Andromeda SDN), storage (Colossus), and security offload, keeping host CPUs dedicated to customer workloads.

Performance & Optimization

Virtualization introduces overhead at multiple levels. Understanding where that overhead comes from — and the techniques to minimize it — is essential for running production workloads efficiently.

Paravirtualization

Paravirtualization modifies the guest OS to be "aware" it's running in a VM. Instead of trapping privileged instructions (expensive), the guest uses optimized hypercalls to communicate directly with the hypervisor.

# Check if paravirtualized drivers are loaded (Linux guest)
lsmod | grep virtio
# virtio_net      — paravirtualized network driver
# virtio_blk      — paravirtualized block storage
# virtio_balloon  — memory ballooning
# virtio_scsi     — paravirtualized SCSI
# virtio_console  — paravirtualized serial console

# Compare network throughput: emulated vs virtio
# Emulated (e1000): ~1 Gbps with high CPU usage
# Virtio-net:       ~10+ Gbps with low CPU usage

# Check virtio devices
lspci | grep -i virtio

# Verify virtio disk performance
fio --name=randread --ioengine=libaio --direct=1 \
    --bs=4k --numjobs=4 --size=1G --runtime=30 \
    --rw=randread --group_reporting

Hardware-Assisted Virtualization (VT-x / AMD-V)

Intel VT-x and AMD-V provide CPU-level support for virtualization, adding new instruction sets and execution modes specifically for hypervisors. This eliminates the need for complex software-based binary translation.

# Verify VT-x/AMD-V support
grep -Ec '(vmx|svm)' /proc/cpuinfo
# Returns number of cores with virtualization support (0 = not supported)

# Check if IOMMU is enabled (required for VT-d/AMD-Vi)
dmesg | grep -i iommu

# Verify EPT/NPT support
cat /sys/module/kvm_intel/parameters/ept  # Intel: Y = enabled
cat /sys/module/kvm_amd/parameters/npt    # AMD: 1 = enabled

# Check nested virtualization support
cat /sys/module/kvm_intel/parameters/nested  # Y = enabled

# Enable nested virtualization (for running VMs inside VMs)
echo "options kvm_intel nested=1" | sudo tee /etc/modprobe.d/kvm.conf
sudo modprobe -r kvm_intel && sudo modprobe kvm_intel

Hands-On Exercises

# Step 1: Verify hardware support
grep -Ec '(vmx|svm)' /proc/cpuinfo
# Should return > 0

# Step 2: Install KVM and tools
sudo apt update
sudo apt install -y qemu-kvm libvirt-daemon-system \
    libvirt-clients bridge-utils virtinst

# Step 3: Add your user to the libvirt group
sudo usermod -aG libvirt $USER
sudo usermod -aG kvm $USER

# Step 4: Verify installation
virsh list --all
systemctl status libvirtd

# Step 5: Create a test VM with cloud-init
sudo virt-install \
    --name test-vm \
    --ram 2048 \
    --vcpus 2 \
    --disk size=10 \
    --os-variant ubuntu22.04 \
    --network network=default \
    --location http://archive.ubuntu.com/ubuntu/dists/jammy/main/installer-amd64/ \
    --extra-args "console=ttyS0" \
    --nographics

# Step 6: Verify VM is running
virsh list
virsh dominfo test-vm

# Step 1: Baseline performance (inside the VM)
# Install benchmarking tools
sudo apt install -y fio sysbench

# CPU benchmark
sysbench cpu --cpu-max-prime=20000 --threads=2 run

# Disk benchmark
fio --name=baseline --ioengine=libaio --direct=1 \
    --bs=4k --numjobs=1 --size=512M --runtime=30 \
    --rw=randread --group_reporting

# Step 2: Apply optimizations (from the host)
# Pin vCPUs
virsh vcpupin test-vm 0 2
virsh vcpupin test-vm 1 3

# Enable huge pages for the VM
virsh edit test-vm
# Add: 

# Step 3: Restart VM and re-run benchmarks
virsh shutdown test-vm
virsh start test-vm

# Step 4: Compare results - document improvements
# Expected: 15-30% improvement in I/O, 5-10% in CPU

# Step 1: Install Open vSwitch
sudo apt install -y openvswitch-switch

# Step 2: Create a virtual switch
sudo ovs-vsctl add-br lab-switch

# Step 3: Create two internal ports on different VLANs
sudo ovs-vsctl add-port lab-switch port-web tag=100 \
    -- set interface port-web type=internal
sudo ovs-vsctl add-port lab-switch port-db tag=200 \
    -- set interface port-db type=internal

# Step 4: Assign IPs
sudo ip addr add 10.0.100.1/24 dev port-web
sudo ip addr add 10.0.200.1/24 dev port-db
sudo ip link set port-web up
sudo ip link set port-db up

# Step 5: Verify VLAN isolation
sudo ovs-vsctl show
sudo ovs-ofctl dump-flows lab-switch

# Step 6: Test connectivity (same VLAN = reachable, cross-VLAN = blocked)
ping -c 3 10.0.100.1  # Should work from VLAN 100
ping -c 3 10.0.200.1  # Should be unreachable from VLAN 100

# Cleanup
sudo ovs-vsctl del-br lab-switch

# Step 1: Create a baseline snapshot
virsh snapshot-create-as test-vm \
    --name "clean-install" \
    --description "Fresh OS install, no applications"

# Step 2: Make changes inside the VM (install software, create files)
virsh console test-vm
# Inside VM: sudo apt install nginx && echo "Hello" > /var/www/html/index.html
# Exit console: Ctrl+]

# Step 3: Create post-change snapshot
virsh snapshot-create-as test-vm \
    --name "with-nginx" \
    --description "nginx installed and configured"

# Step 4: Simulate disaster (corrupt something)
virsh console test-vm
# Inside VM: sudo rm -rf /etc/nginx
# Exit console: Ctrl+]

# Step 5: Recover by reverting to snapshot
virsh snapshot-revert test-vm "with-nginx"

# Step 6: Verify recovery
virsh console test-vm
# Inside VM: nginx -t && curl localhost
# Should show "Hello"

# Step 7: List and clean up snapshots
virsh snapshot-list test-vm --tree
virsh snapshot-delete test-vm "clean-install"

Conclusion & Next Steps

You now have a deep understanding of virtualization technology:

• Hypervisor types — Type 1 (ESXi, KVM, Hyper-V, Xen) for production, Type 2 (VirtualBox, Workstation) for development
• Virtual CPUs — scheduling, overcommit ratios, CPU pinning for performance
• Virtual memory — overcommit, ballooning, huge pages, KSM deduplication
• Virtual networking — vSwitches, VLANs, SR-IOV for near-native performance
• Virtual storage — thin provisioning, snapshots, live migration
• Cloud platforms — Nitro, Azure Hypervisor, Titanium and their hardware offload approach
• Performance optimization — paravirtualization, hardware-assisted virtualization, NUMA awareness