Налаштування віртуалізації KVM/QEMU на Linux під ключ

Налаштування віртуалізації KVM/QEMU на Linux

Іноді bare metal упирається у вартість або гнучкість — і тоді приходить KVM/QEMU. Клієнти часто приходять з проблемою: "Хочемо віртуалізацію, але без прив'язки до вендора та з повним контролем". Ми налаштовуємо KVM/QEMU під ключ, вписуючи його у ваш стек: Terraform, Ansible, GitOps, Prometheus. Без GUI, тільки CLI та API — максимальна продуктивність та нульові ліцензії. За останні 5 років ми реалізували понад 50 проектів віртуалізації на базі KVM — від невеликих лабораторій до продуктових кластерів на 200+ віртуальних машин. Середня економія бюджету порівняно з комерційними гіпервізорами — близько 40% за рахунок відсутності ліцензійних відрахувань.

Чому KVM/QEMU обирають для продакшену?

Proxmox зручний, але його оновлення та ліцензія (Community vs Enterprise) можуть не підійти строгим середовищам. KVM/QEMU — це модуль ядра Linux: ви отримуєте нативну продуктивність, а не шар абстракції. Згідно з документацією Red Hat, з VirtIO гості працюють на 95–98% від bare metal. Міграція live-migration, балансування CPU через virsh vcpupin, SLO під 99.9% — все це доступно «з коробки» без додаткових надбудов. Наприклад, в одному з проектів ми замінили VMware vSphere на KVM — витрати на ліцензії впали в 5 разів, а продуктивність зросла на 12% завдяки прямому доступу до ядра.

Як забезпечити відмовостійкість KVM?

Для високодоступних середовищ використовуємо комбінацію live-migration та роздільного сховища (NFS, Ceph). Налаштування блокування за схемою "2-3 хости + Quorum" через corosync/pacemaker. Середній час відновлення (RTO) при відмові вузла — не більше 15 хвилин. План бекапів: снапшоти qcow2 кожні 4 години, повний бекап раз на добу на окремий сервер. Для критичних ВМ налаштовуємо автоматичний перезапуск на сусідньому хості.

Що ми робимо в рамках налаштування KVM/QEMU

1. Аудит заліза: перевірка підтримки VT-x/AMD-V, IOMMU, NUMA. Оптимізуємо розташування vCPU та пам'яті. У типовому сервері з 2 сокетами по 16 ядер та 256 ГБ RAM можна розмістити до 30 середньо-навантажених ВМ.
2. Встановлення та конфігурація: qemu-kvm, libvirt-daemon, bridge-utils, virtinst. Налаштування дефолтної мережі (NAT або bridge).
3. Мережа: створення bridge-інтерфейсів, VLAN (bridge per VLAN), Open vSwitch за бажанням. Гарантуємо NetworkPolicy та ізоляцію. Приклад: для мікросервісної архітектури організовуємо по одному bridge на кожен проект.
4. Сховища: qcow2 з cache=none,io=native, LVM thin provisioning. Підключаємо NFS/Ceph для live-migration.
5. Шаблони ВМ: cloud-init, образи Ubuntu 22.04 LTS, Debian 12, CentOS Stream 9. Все через virt-install або Terraform.
6. Моніторинг: Prometheus + libvirt_exporter, Grafana дашборди. Метрики: CPU steal, disk latency, memory ballooning.
7. Бекапи: virt-backup або rsync снапшотів. RPO — 1 година, RTO — 15 хвилин.

Як налаштувати моніторинг KVM?

Встановлюємо libvirt_exporter, прикручуємо до Prometheus. На Grafana є готові дашборди. Ключові метрики:

• kvm_domain_info — стан гостей
• kvm_domain_cpu_time_seconds — steal-час
• kvm_domain_balloon_current_bytes — витоки пам'яті

Alerting за MTTR та SLO. Runbook: якщо steal вище 10% — перевіряємо CPU pinning або навантаження сусідніх ВМ.

Мережевий bridge для ВМ

Створюємо Linux bridge так:

# /etc/netplan/01-bridge.yaml (Ubuntu)
network:
  version: 2
  ethernets:
    enp3s0:
      dhcp4: false
  bridges:
    br0:
      interfaces: [enp3s0]
      addresses: [192.168.1.10/24]
      gateway4: 192.168.1.1
      nameservers:
        addresses: [8.8.8.8]
      parameters:
        stp: false
        forward-delay: 0
netplan apply

Для VLAN-тегованого трафіку створюємо br-vlan300 поверх enp3s0.300 — кожен VLAN отримує свій bridge, ВМ підключаються до потрібного.

Створення ВМ через qemu-system та virt-install

# Створення диска ВМ (qcow2 — thin provisioned, підтримує снапшоти)
qemu-img create -f qcow2 /var/lib/libvirt/images/webserver01.qcow2 40G
# Встановлення ВМ з ISO
virt-install \
  --name webserver01 \
  --ram 4096 \
  --vcpus 4 \
  --cpu host \
  --disk path=/var/lib/libvirt/images/webserver01.qcow2,format=qcow2,bus=virtio \
  --network bridge=br0,model=virtio \
  --os-variant ubuntu22.04 \
  --cdrom /tmp/ubuntu-22.04-server.iso \
  --graphics none \
  --console pty,target_type=serial \
  --extra-args 'console=ttyS0,115200n8'

Ключовий момент: --cpu host передає реальні прапорці процесора в ВМ — максимальна продуктивність. Якщо ВМ потрібно мігрувати між хостами з різними CPU — використовуємо --cpu qemu64 для сумісності.

bus=virtio та model=virtio — паравіртуальні драйвери для диска та мережі. Продуктивність значно вища, ніж у емульованого IDE/e1000 (в 3–5 разів). Гостьова ОС повинна мати VirtIO драйвери (в Linux вони вбудовані в ядро, Windows вимагає окремого встановлення).

Snapshots та клонування

# Створення снапшоту перед оновленням
virsh snapshot-create-as webserver01 \
    --name "before-update" \
    --description "Before kernel update" \
    --atomic

# Список снапшотів
virsh snapshot-list webserver01

# Відкат до снапшоту
virsh snapshot-revert webserver01 before-update

# Клонування ВМ
virt-clone --original webserver01 \
    --name webserver02 \
    --file /var/lib/libvirt/images/webserver02.qcow2

Снапшоти qcow2 зберігають тільки delta від базового образу. При глибокому ланцюжку снапшотів продуктивність диска падає — зливаємо старі снапшоти через qemu-img commit. Управління снапшотами здійснюється через libvirt.

Продуктивність та tuning

Для I/O-навантажених ВМ вмикаємо cache=none,io=native на дисках — вимикає подвійне кешування між guest та host. Для мережевих навантажень — multiqueue на virtio-net: кількість черг = кількість vCPU ВМ.

CPU pinning для latency-sensitive робочих навантажень:

# Прив'язка vCPU ВМ до конкретних фізичних ядер virsh vcpupin webserver01 0 2 virsh vcpupin webserver01 1 3 

Порівняння KVM з альтернативами

Що входить у нашу роботу з налаштування KVM/QEMU

• Аудит інфраструктури: аналіз поточних навантажень, підбір CPU/RAM/дисків.
• Встановлення та конфігурація: KVM, libvirt, bridge, сховища, cloud-init.
• Створення шаблонів ВМ: Ubuntu, Debian, CentOS, Windows Server (з VirtIO драйверами).
• Інтеграція моніторингу: Prometheus + Grafana дашборди, алерти за SLO.
• Документація: схема мережі, runbook з відновлення, план бекапів.
• Навчання команди: 2–3 сесії з управління virsh, virt-manager (опціонально).

Ми працюємо з KVM вже понад 5 років, реалізували проекти для 50+ компаній — від стартапів до enterprise.

Терміни налаштування: від 3 до 5 робочих днів — під ключ, з гарантією SLA 99.9%.

Замовте аудит вашої інфраструктури — оцінимо проект та запропонуємо оптимальне рішення. Зв'яжіться з нами для консультації.