Proxmox VE — практическо ръководство

Част 4: Виртуални машини (KVM)

Тук вече слагам гост върху host-а, подготвен в предишните части. Machine type, CPU type, VirtIO SCSI, guest agent и как изграждам cloud-init темплейт, от който клонирам нови машини за секунди вместо да инсталирам ОС всеки път на ръка.

Тази част е за KVM VMs, не за LXC. VM тук означава пълна виртуална машина със собствен kernel — за системни контейнери, които споделят kernel-а на host-а, ще говоря отделно в Част 5.

1. Създаване на VM — какво реално избирам в wizard-а

Wizard-ът за нова VM (Create VM) минава през няколко таба, но само няколко от полетата в тях реално имат последствия по-нататък. Останалото са разумни defaults, които рядко пипам.

General
VMID, име
→
OS
ISO / guest type
→
System
machine, BIOS, agent
↓
Disks
CPU / Memory
Network

2. Machine Type — i440fx срещу q35

Machine type определя виртуалния „дънна платка“ модел на VM. Proxmox по подразбиране предлага i440fx — стар, но много съвместим chipset. q35 е по-съвременен, поддържа виртуална PCIe шина и е нужен, ако планирам PCIe/GPU passthrough.

Machine type Кога го избирам
i440fx (default) Обикновена Linux VM без нужда от PCIe passthrough — работи без проблем в повечето случаи.
q35 Планирам GPU/PCIe passthrough, искам vIOMMU емулация, или просто предпочитам по-модерен virtual hardware layout.
Личен избор: за нови Linux VMs без passthouth нужди почти винаги слагам q35 directно — chipset-ът е по-малко ограничен и не виждам сериозна причина да оставам на i440fx, освен инерция. За Windows guest, обаче, machine version се фиксира при създаването на VM-а, така че избора тук е по-труден за смяна по-късно.

3. BIOS: SeaBIOS срещу OVMF (UEFI)

SeaBIOS е default и покрива повечето сценарии. Минавам на OVMF (UEFI), когато:

  • Планирам PCIe/GPU passthrough;
  • Гостовата ОС изисква UEFI boot (например по-нови Windows инсталации със Secure Boot);
  • Искам TPM emulation за Windows 11 изисквания.
OVMF изисква отделен EFI disk. Ако избера OVMF, трябва да добавя малък допълнителен диск за EFI vars — Proxmox го предлага автоматично в wizard-а, но не забравям да го включа, ако конфигурирам VM ръчно през CLI.

4. CPU Type — kvm64 срещу host

Това е решение, което директно засяга и производителност, и live migration:

CPU type Ефект
kvm64 (default) Генеричен, консервативен CPU модел. Позволява live migration между хостове с различни физически CPU-та.
host VM вижда реалните CPU features на host-а — максимална производителност, но live migration между различни CPU модели вече не работи надеждно.

Практическото ми правило: на единичен host без clustering ползвам host — няма какво да мигрирам towards, а производителността е реална разлика при CPU-интензивни workload-и. В клъстер с разнородни node-ове (Част 8) се връщам към по-консервативен, но съвместим тип.

Практическа забележка: някои по-нови дистрибуции (например по-нови RHEL-базирани системи) очакват определено ниво CPU features (x86-64-v2 и нагоре). Ако host CPU-то е достатъчно старо, а дистрибуцията изисква по-нов feature set, помага явен избор на конкретен ниво тип вместо generic kvm64, а не задължително host.

5. Disk — VirtIO SCSI, discard, SSD emulation

За SCSI controller избирам VirtIO SCSI single — дава по-добра производителност от емулирания SATA/IDE и позволява iothread на диск, а не общ за целия controller.

ТИПИЧНА КОНФИГУРАЦИЯ НА ДИСК
scsihw: virtio-scsi-single
scsi0: local-lvm:vm-101-disk-0,discard=on,ssd=1,iothread=1
  • discard=on — позволява TRIM да минава от гост към storage backend-а (важно при thin provisioning);
  • ssd=1 — представя диска на госта като SSD, не механичен HDD (влияе на вътрешна оптимизация на госта);
  • iothread=1 — диска получава собствен I/O thread, вместо да чака общия.
Discard има смисъл само върху thin storage. Върху ZFS или LVM-thin от Част 3, discard=on реално връща освободено пространство обратно на pool-а. Върху thick LVM или обикновен диск ефектът е минимален.

6. qemu-guest-agent — инсталирам го винаги

Guest agent-ът е малка услуга вътре в госта, която комуникира с Proxmox host-а — дава коректно IP адреси в UI, позволява чист shutdown вместо force-stop, и коректен filesystem freeze при snapshot.

В Proxmox: Options → QEMU Guest Agent → Enabled. Вътре в госта (Debian/Ubuntu):

TERMINAL (вътре в госта)
apt update
apt install -y qemu-guest-agent
systemctl enable --now qemu-guest-agent
Ако включа agent в Proxmox, но не го инсталирам в госта, VM-ът изглежда „забива“ при shutdown команди от UI, защото Proxmox чака отговор от агент, който не съществува. Ако видя това поведение, първо проверявам дали agent-ът реално работи вътре, преди да заключа, че host-ът има проблем.

7. Cloud-init темплейт — създавам VM веднъж, клонирам многократно

За Linux VMs почти никога не минавам ръчна ISO инсталация повторно. Изграждам темплейт от официален cloud image веднъж, и клонирам от него нататък.

1. ИЗТЕГЛЯНЕ НА CLOUD IMAGE
wget https://cloud-images.ubuntu.com/noble/current/noble-server-cloudimg-amd64.img
2. СЪЗДАВАНЕ НА БАЗОВА VM
qm create 9000 \
  --name ubuntu-noble-template \
  --memory 2048 --cores 2 \
  --net0 virtio,bridge=vmbr0 \
  --machine q35 \
  --agent enabled=1
3. ИМПОРТ НА ДИСКА
qm importdisk 9000 noble-server-cloudimg-amd64.img local-lvm

qm set 9000 \
  --scsihw virtio-scsi-single \
  --scsi0 local-lvm:vm-9000-disk-0,discard=on,ssd=1
4. ДОБАВЯНЕ НА CLOUD-INIT ДИСК И BOOT ПОРЯДЪК
qm set 9000 --ide2 local-lvm:cloudinit
qm set 9000 --boot order=scsi0
qm set 9000 --serial0 socket --vga serial0
5. ПРЕВРЪЩАНЕ В TEMPLATE
qm template 9000

От тук нататък, нова машина е просто клониране:

КЛОНИРАНЕ НА НОВА VM ОТ TEMPLATE
qm clone 9000 101 --name web1 --full

qm set 101 \
  --ipconfig0 ip=192.168.1.101/24,gw=192.168.1.1 \
  --sshkeys ~/.ssh/id_rsa.pub \
  --ciuser fedia

qm start 101
Резултат: нова VM с готова мрежова конфигурация и SSH ключ, стартирана за секунди, без нито една ръчна стъпка от инсталационен ISO. Това е разликата между „правя VM“ и „правя VMs“.

8. CLI срещу wizard — кога избирам кое

За единична VM с еднократна цел, wizard-ът е по-бърз и по-малко склонен към печатни грешки. За темплейти, скриптируеми deployment-и или повтарящи се конфигурации, CLI ми дава възпроизводимост — мога да запазя командите като скрипт и да получа идентичен резултат следващия път.

9. Типични грешки

  • Оставяне на CPU type host в клъстер с разнородни node-ове, което чупи live migration неочаквано.
  • Включен guest agent в Proxmox, но неинсталиран вътре в госта — VM „забива“ при shutdown от UI.
  • OVMF без добавен EFI disk — VM не bootва, а причината не е очевидна от логовете на пръв поглед.
  • discard=on върху storage, който не поддържа thin provisioning — очакван ефект, който не се случва.
  • Клониране на темплейт без промяна на --sshkeys/мрежовата конфигурация — нови VMs с еднакъв SSH ключ или сблъскващи се IP адреси.

10. Най-важното от тази част

  • q35 е по-съвременният machine type и е задължителен за PCIe/GPU passthrough.
  • CPU type host дава производителност, но чупи live migration между различни физически CPU-та.
  • VirtIO SCSI single с discard, ssd и iothread е предпочитаната конфигурация за диск.
  • qemu-guest-agent трябва да е включен в Proxmox и инсталиран вътре в госта — не само едното.
  • Cloud-init темплейт от cloud image + qm clone замества ръчна инсталация за всяка нова Linux VM.

Заключение

Разликите между default настройките на wizard-а и настройките, които реално използвам, не са козметични. Machine type, CPU type и storage конфигурацията на диска определят колко бързо работи VM-ът, колко лесно го мигрирам по-късно и колко предвидимо се държи при snapshot или backup.

В следващата част минавам към LXC контейнерите — как се различават практически от KVM VMs, разликата между privileged и unprivileged контейнер, и кога избирам едното пред другото за конкретна задача.