Installing and Using KVM on Ubuntu: Kernel-Level Virtualization for Real Servers – ITFROMZERO

Table of Contents

VirtualBox, VMware, Vagrant, KVM — Which One Should You Pick?

When I first got into virtualization on Linux, I worked my way through VirtualBox, then Vagrant for managing dev VMs, before finally switching to KVM. Each tool has its place — but if you want to run stable VMs on a real Ubuntu server for the long haul, KVM is the only one worth committing to.

Quick breakdown of each tool:

VirtualBox: easy to use, has a GUI, but lower performance and not suitable for production
Vagrant: a tool for managing VMs, not a hypervisor — it calls VirtualBox or KVM underneath. Great for dev workflows, not for real servers
VMware Workstation/ESXi: powerful, but requires a paid license
KVM: a Type-1 hypervisor built directly into the Linux kernel, near bare-metal performance, completely free

This blog already has a post on Vagrant — perfect when you need to spin up a dev environment fast. This article is a different story: KVM as a serious virtualization platform for running production workloads.

Real-World Pros and Cons of KVM

Strengths

High performance: KVM is a Type-1 hypervisor — VMs run directly on hardware through CPU virtualization extensions (Intel VT-x / AMD-V). Real-world benchmarks show overhead typically under 5% compared to bare-metal
Kernel integration: Since Linux 2.6.20, KVM has been part of the official kernel. No external drivers to install, no random compatibility headaches
Rich ecosystem: libvirt, virt-manager, virsh — and even Proxmox VE (the default hypervisor for countless homelabs and SME data centers) are all built on top of KVM
Live migration: Move a running VM to another host with zero downtime — an enterprise-grade feature available out of the box, completely free

Weaknesses

No built-in GUI (on headless servers): You have to use virsh via CLI, or install virt-manager on a client machine and connect remotely
Requires hardware virtualization support: Your CPU must have Intel VT-x or AMD-V. Most modern machines do, but you may need to enable it in the BIOS first
Bridge networking has a learning curve: The first time I set it up, I spent nearly two hours figuring out why my VMs couldn’t reach the internet — the key was getting the order of bridge and physical interface configuration right

When Should You Choose KVM Over Other Options?

I run a homelab on Proxmox VE (built on KVM) — 12 VMs and containers used as a playground to test everything before pushing to production. KVM is the right call when:

You need to run VMs 24/7 on an Ubuntu server (VPS, dedicated server, homelab)
Your workload demands real performance — databases, compile servers, CI/CD runners
You want full control without depending on a cloud provider
You need stronger isolation than Docker (each VM has its own kernel, completely separate)

Just need a local dev environment for testing code? Vagrant + VirtualBox is still perfectly fine and faster to set up.

How to Install KVM on Ubuntu

Step 1: Check Whether Your CPU Supports Virtualization

Before installing anything, check your CPU:

# Kiểm tra Intel VT-x hoặc AMD-V
egrep -c '(vmx|svm)' /proc/cpuinfo

# Nếu output > 0 là OK
# vmx = Intel VT-x, svm = AMD-V

Getting 0? Go into your BIOS and enable Intel Virtualization Technology (or AMD-V/SVM). If you’re running inside another VM (nested virtualization), you’ll need to enable nested VM support on the host first.

You can also double-check with kvm-ok:

sudo apt install -y cpu-checker
sudo kvm-ok

# Output mong đợi:
# INFO: /dev/kvm exists
# KVM acceleration can be used

Step 2: Install KVM and Required Packages

sudo apt update
sudo apt install -y \
  qemu-kvm \
  libvirt-daemon-system \
  libvirt-clients \
  bridge-utils \
  virtinst \
  virt-manager

What each package does:

qemu-kvm: QEMU with KVM acceleration — the actual engine that runs your VMs
libvirt-daemon-system: the VM management daemon (libvirtd)
libvirt-clients: CLI tools (virsh, virsh-list, etc.)
bridge-utils: create bridge networks for VMs
virtinst: provides the virt-install command for creating VMs from the CLI
virt-manager: GUI for managing VMs (optional, useful when you have a desktop)

Step 3: Add Your User to the libvirt Group

sudo usermod -aG libvirt $(whoami)
sudo usermod -aG kvm $(whoami)

# Logout và login lại để group có hiệu lực
# Hoặc dùng lệnh này để apply ngay mà không cần logout:
newgrp libvirt

Verify that libvirtd is running:

sudo systemctl enable --now libvirtd
sudo systemctl status libvirtd

# Kiểm tra connection
virsh -c qemu:///system list

Step 4: Create Your First VM with virt-install

Once you’ve downloaded an ISO, use virt-install to provision a VM from the command line:

# Download ISO Ubuntu 22.04 LTS (kiểm tra version mới nhất tại releases.ubuntu.com)
wget -P /var/lib/libvirt/images/ \
  https://releases.ubuntu.com/22.04/ubuntu-22.04.5-live-server-amd64.iso

# Tạo VM với virt-install
sudo virt-install \
  --name ubuntu-test \
  --ram 2048 \
  --vcpus 2 \
  --disk path=/var/lib/libvirt/images/ubuntu-test.qcow2,size=20,format=qcow2 \
  --cdrom /var/lib/libvirt/images/ubuntu-22.04.5-live-server-amd64.iso \
  --network network=default \
  --os-variant ubuntu22.04 \
  --graphics vnc,listen=0.0.0.0 \
  --noautoconsole

The VM will boot from the ISO. Connect to the installation screen via a VNC client (default port 5900):

# Xem port VNC của VM
virsh vncdisplay ubuntu-test
# Ví dụ output: :0 (tức là port 5900)

Everyday virsh Commands You’ll Actually Use

Here’s the set of commands I reach for almost every day — worth bookmarking:

# Liệt kê tất cả VM (đang chạy và đã tắt)
virsh list --all

# Bật / tắt / restart VM
virsh start ubuntu-test
virsh shutdown ubuntu-test    # graceful shutdown
virsh destroy ubuntu-test     # force stop (tương đương rút điện)
virsh reboot ubuntu-test

# Xem thông tin chi tiết VM
virsh dominfo ubuntu-test

# Snapshot — cực kỳ hữu ích trước khi thử nghiệm gì đó
virsh snapshot-create-as ubuntu-test snap-before-update
virsh snapshot-list ubuntu-test
virsh snapshot-revert ubuntu-test snap-before-update

# Clone VM
virt-clone \
  --original ubuntu-test \
  --name ubuntu-clone \
  --file /var/lib/libvirt/images/ubuntu-clone.qcow2

# Xóa VM hoàn toàn (bao gồm disk)
virsh undefine ubuntu-test --remove-all-storage

Networking Configuration: Bridge vs NAT

By default, KVM uses a NAT network (virbr0) — VMs can reach the internet but aren’t accessible from outside. On a homelab or production server, you’ll typically want VMs to have their own IP directly on the LAN, just like a physical machine. That’s when you need a bridge network.

Creating a bridge on Ubuntu 22.04 with Netplan:

# /etc/netplan/01-bridge.yaml
network:
  version: 2
  renderer: networkd
  ethernets:
    eno1:
      dhcp4: false
  bridges:
    br0:
      interfaces: [eno1]
      dhcp4: true
      parameters:
        stp: false
        forward-delay: 0

sudo netplan apply

# Tạo VM dùng bridge network
sudo virt-install \
  --name ubuntu-prod \
  --network bridge=br0 \
  # ... các option khác

A word of warning from personal experience: the first time I did this, I lost SSH access to the server because I misconfigured the bridge. Expensive lesson learned — test on a non-critical VM first, or make sure you have direct console access to the server before touching network config.

Wrapping Up

KVM isn’t the easiest thing to set up — VirtualBox wins that category hands down. But ease of setup isn’t the right criterion for choosing a production hypervisor. After 6 months running KVM, from a 12-VM homelab to real VPS instances, performance has never once been a concern worth raising.

Once you’re comfortable with virsh, the natural next step is picking a web UI. Cockpit with the virtual machines plugin is lightweight and more than capable for a single server. For full cluster management, Proxmox VE is the answer — but that’s a topic for another post.