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

↓

DisksCPU / MemoryNetwork

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 контейнер, и кога избирам едното пред другото за конкретна задача.