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

Част 2: Инсталация и първи стъпки

Тук минавам от теорията към конкретния host: избор на hardware, самата инсталация, ext4 срещу ZFS и настройките, които правя веднага след първото влизане — преди да е сложена каквато и да е VM отгоре.

Тази част е за host-а, не за гостите. Не създавам нито една VM или LXC контейнер тук. Целта е да имам чист, актуализиран, разбираем Proxmox host, върху който следващите части ще строят без изненади.

1. Hardware — какво реално ми трябва

Официалните минимални изисквания на Proxmox VE са скромни, но „минимални“ и „разумни за реална употреба“ не са едно и също нещо. Ето какво гледам аз, когато избирам или подготвям машина за host:

  • CPU с hardware virtualization — Intel VT-x или AMD-V. Без това KVM виртуалните машини изобщо не тръгват нормално.
  • RAM — минимумът в документацията е нисък, но на практика не слизам под 16 GB дори за домашна лаборатория. Ако планирам ZFS, добавям резерв — ZFS ARC обича памет.
  • Storage — SSD или NVMe за host-а и за VM дисковете. Механичен HDD все още има място, но само за архивни данни или backup дестинация, не за активни VMs.
  • Мрежа — поне един стабилен gigabit интерфейс. Ако планирам VLAN сегментация по-нататък (Част 6), гледам да имам мрежова карта, която Linux разпознава без допълнителни драйвери.
Честна забележка: няма нужда от enterprise хардуер, за да започнеш. Стар desktop или mini PC с VT-x е напълно достатъчен, за да научиш платформата. Enterprise хардуер (ECC RAM, redundant storage) става важен, когато данните вътре престанат да са „тестови“.

2. Подготовка на инсталационния носител

Изтеглям официалния ISO образ от proxmox.com/downloads и го записвам на USB флашка. На Linux/macOS използвам директно dd, на Windows — Rufus или balenaEtcher.

TERMINAL (Linux/macOS)
sudo dd if=proxmox-ve_*.iso of=/dev/sdX bs=4M status=progress conv=fsync
Провери /dev/sdX внимателно. Грешно устройство тук означава изтрити данни на грешния диск. Проверявам с lsblk преди да пусна dd, не по памет.

3. BIOS/UEFI — какво проверявам преди инсталация

Преди да заредя инсталатора, влизам в BIOS/UEFI и проверявам:

  • Intel VT-x / AMD-V — трябва да е активирано, иначе KVM VMs изобщо няма да стартират.
  • VT-d / AMD-Vi (IOMMU) — не ми трябва веднага, но ако предвиждам PCIe/GPU passthrough в бъдеще, е по-лесно да го включа сега, отколкото да се връщам после.
  • Boot mode — избирам UEFI, освен ако конкретният хардуер няма причина да е другояче.

4. Самата инсталация

Инсталаторът на Proxmox VE е графичен и линеен — избор на target disk, timezone, парола за root, мрежова конфигурация. Тук спирам на едно решение, което има реални последствия по-нататък: файловата система за host storage.

Опция Кога я избирам
ext4 Единичен диск, без нужда от snapshots на ниво storage, най-прост вариант за старт.
ZFS (RAID1/RAIDZ) Имам два или повече диска и искам redundancy, snapshots и checksums на ниво filesystem.
BTRFS Технически налична опция в инсталатора, но лично не я използвам за host storage — предпочитам утвърдените ZFS или ext4.
ZFS изисква повече RAM заради ARC кеша и не е задължителна отправна точка. Storage темата заслужава собствена част (Част 3) — тук просто избирам достатъчно съзнателно, за да не се налага да преинсталирам host-а само заради тази стъпка.

5. Първо влизане в Web UI

След рестарт, host-ът е достъпен на:

BROWSER
https://:8006

Влизам с root и паролата, зададена по време на инсталацията, realm Linux PAM. Браузърът ще се оплаче за self-signed сертификат — това е нормално за прясна инсталация.

6. Repository fix — първото нещо, което оправям

Прясно инсталиран Proxmox VE (текущата стабилна линия е Proxmox VE 9, върху Debian 13 „trixie“) е конфигуриран по подразбиране към enterprise repository, който изисква платен subscription key. Без такъв, apt update връща 401 Unauthorized.

Най-безопасният начин да го оправя е през самия Web UI:

Node → Updates → Repositories
↓
Disable реда с pve-enterprise
↓
Add → No-Subscription repository

Аз предпочитам CLI, текущият формат на repository файловете е deb822 (.sources), не старият едноредов .list формат:

/etc/apt/sources.list.d/pve-no-subscription.sources
Types: deb
URIs: http://download.proxmox.com/debian/pve
Suites: trixie
Components: pve-no-subscription
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg

Файлът pve-enterprise.sources (или старият pve-enterprise.list на по-стари инсталации) трябва да бъде disabled или изтрит, за да не се получава грешка при следващ apt update.

No-subscription repository не е „нестабилна“ версия на Proxmox. Съдържа същите пакети като enterprise repo, просто без допълнителния слой тестване, който предхожда публикуването в enterprise repository. За домашна лаборатория и тестова среда е напълно разумен избор. За критична production среда, официалната препоръка на Proxmox остава enterprise subscription.

6.1. А какво да правя с popup-а за subscription

При всяко влизане в Web UI без активен subscription се появява напомнящ popup. Той е козметичен — не ограничава нито една функционалност, включително clustering, HA и ZFS. Съществуват community скриптове, които го премахват чрез патчване на proxmox-widget-toolkit, но лично не си правя този труд: промяната се презаписва при всяка актуализация на пакета и трябва да се прилага наново. За домашна употреба просто затварям попъпа — не си струва поддръжката на hack, който няма реален функционален ефект.

7. Update и reboot

След repository fix-а, първото нещо е пълна актуализация:

TERMINAL
apt update
apt full-upgrade -y
Използвам full-upgrade, не обикновен upgrade. Proxmox понякога сменя приоритетите на пакети между версии (например при нов kernel), а обикновеният upgrade може да откаже да го инсталира, за да не премахне пакети.

Ако е инсталиран нов kernel, рестартирам host-а, преди да продължа нататък:

TERMINAL
reboot

8. Hostname и /etc/hosts — дребно нещо, което чупи всичко после

Това е една от най-подценяваните проверки. Ако hostname-ът на host-а не съвпада коректно със записа в /etc/hosts, услуги като pvestatd или бъдещо clustering (Част 8) започват да се държат непредвидимо, без ясна причина в logs на пръв поглед.

ПРОВЕРКА
hostname
hostname -f
cat /etc/hosts

Очаквам /etc/hosts да съдържа коректен ред, свързващ статичния IP на host-а с пълното му FQDN и с краткото име, например:

/etc/hosts
192.168.1.10  pve1.home.lan  pve1
Статичен IP, не DHCP. За hypervisor host не разчитам на DHCP lease, който може да се смени. Задавам статичен адрес през инсталатора или после в /etc/network/interfaces.

9. Добавяне на storage за ISO образи

Преди да мога да инсталирам каквато и да е VM (Част 4), ми трябва storage, на който да качвам ISO образи. По подразбиране local storage-ът вече поддържа тип ISO image, но ако имам отделен диск или NAS дял за целта, го добавям от Datacenter → Storage → Add.

Качване на ISO ръчно през CLI, ако не искам да чакам upload през браузъра:

TERMINAL
scp ubuntu-24.04-live-server-amd64.iso \
  root@pve1:/var/lib/vz/template/iso/

10. Типични грешки на този етап

  • Инсталация без предварителна проверка дали VT-x/AMD-V е активиран в BIOS.
  • Оставяне на enterprise repository активен, докато apt update просто не работи.
  • DHCP адрес за самия host, който после се сменя и чупи достъпа до Web UI.
  • Прескачане на /etc/hosts проверката — работи в началото, чупи се при clustering.
  • Инсталиране на ZFS без достатъчно RAM резерв за ARC, а после чудене защо host-ът е бавен.
  • Трошене на попъп-а за subscription с hack, който се разпада при следваща актуализация — и после паника, че „нещо счупи Proxmox“.

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

  • Virtualization extensions (VT-x/AMD-V) са задължителни в BIOS, преди изобщо да инсталирам.
  • Изборът между ext4 и ZFS при инсталация има реални последствия по-нататък.
  • Enterprise repository изисква платен subscription — за домашна употреба минавам на no-subscription repository.
  • Текущият repository формат е deb822 (.sources), не старият едноредов .list.
  • Subscription popup-ът е козметичен и не влияе на функционалността.
  • Статичен IP и коректен /etc/hosts спестяват объркващи проблеми по-нататък.
  • apt full-upgrade, не обикновен upgrade, за да не се блокират kernel актуализации.

Заключение

Тази част не съдържа нищо ефектно — няма създадена нито една VM. Именно затова я пиша отделно. Повечето проблеми, които съм гонил по-късно из логовете на Proxmox, се коренят точно тук: грешен избор на filesystem при инсталация, необновен repository или несъответствие в /etc/hosts, което цъфва месеци по-късно при опит за clustering.

Сега host-ът е актуален, достъпен на статичен адрес, с работещ repository и готов storage за ISO образи. В следващата част минавам на storage в дълбочина — ZFS, LVM и directory storage, кой backend за какъв сценарий, thin provisioning и как работят snapshots на практика.