Cloud-Init у Proxmox – механізм первинної ініціалізації Linux-віртуалки з шаблону. Він підставляє hostname, користувача, SSH-ключі, мережу й частину базових параметрів без входу в консоль. Одна підготовлена VM потім клонується в робочі машини за кілька хвилин.
Коли на вузлі регулярно з’являються тестові Debian або Ubuntu, встановлення з ISO швидко створює дрібний безлад. Машини починають відрізнятися мережею, користувачами або ключами. Шаблон прибирає ці розбіжності ще на старті.
Тут зібрана робоча схема: який образ брати, як імпортувати його в Proxmox, як додати cloud-init диск, де задати IP і DNS, як передати SSH-ключі та чим перевірити результат після першого старту.
Що саме відбувається після першого запуску VM
Cloud-Init у Proxmox працює через seed-диск з метаданими. Пакет cloud-init всередині гостя читає їх під час старту й застосовує конфігурацію. Для homelab цього вистачає, щоб піднімати окремі VM з різними IP, hostname і ключами з одного шаблону.
Proxmox тут лише генерує user-data, мережеву конфігурацію і метадані інстанса. Саму логіку виконує гостьова ОС. Через це більшість поломок ховається не в панелі, а всередині Linux: пакет не встановлено, служба не стартує, образ чекає інший datasource, або мережу перехоплює NetworkManager чи власний netplan.
Для стартового bootstrap це закриває майже все потрібне. Далі вже можна підключати конфіг-менеджмент, якщо він взагалі потрібен. Найчастіше саме перша хвилина життя VM створює найбільше ручної роботи, і тут шаблон дає найбільший виграш.
Опис механіки є в документації Proxmox VE, а фази ініціалізації та формат даних описані на офіційному сайті Cloud-Init.
Який образ брати під шаблон
Для шаблону потрібен cloud image, а не звичайний інсталяційний ISO. Такий образ уже містить cloud-init, коректну розмітку диска і стартові налаштування для віртуального середовища. У Proxmox найчастіше використовують Debian або Ubuntu у форматі .qcow2 чи .img.
Перевірка тут проста: образ має містити пакет cloud-init і вміти читати datasource від гіпервізора. У більшості актуальних Debian та Ubuntu це працює без доробок. Проблеми частіше з minimal-образами, де пакет встановлено, але мережа після старту не підхоплюється через інший рендерер.
Що перевірити всередині образу перед шаблонізацією
Іноді достатньо один раз завантажити образ як тестову VM і подивитися, чи є пакет, чи стартує служба і хто керує мережею. Для Debian та Ubuntu вистачає таких команд:
dpkg -l | grep cloud-init systemctl status cloud-init cloud-init --version ls /etc/netplan systemctl status systemd-networkd systemctl status NetworkManager
Якщо всередині вже лишилися кастомні мережеві файли, старі SSH host keys або зайві користувачі, шаблон з такого диска краще не робити. Усі ці залишки потім розмножуються в клонах. Саме через це чистий cloud image зазвичай кращий за колишню робочу VM, навіть якщо її хочеться зекономити й переобернути в template.
Підготовка шаблону VM без встановлення з ISO
Найкоротший шлях – створити порожню VM, імпортувати cloud image, додати cloud-init диск, увімкнути серійну консоль і перетворити машину на template. Після цього клонування йде без повторного встановлення системи.
Нижче приклад для Debian або Ubuntu на storage local-lvm. Файл образу вже лежить на вузлі, наприклад у /var/lib/vz/template/iso/. Для прикладу використано VM ID 9000.
- Створити порожню VM з базовими параметрами.
- Імпортувати диск з cloud image.
- Під’єднати диск як
scsi0черезvirtio-scsi-pci. - Додати cloud-init диск.
- Увімкнути серійну консоль і задати boot order.
- Перетворити VM на шаблон.
qm create 9000 --name ubuntu-2404-cloud-template --memory 2048 --cores 2 --net0 virtio,bridge=vmbr0 qm importdisk 9000 /var/lib/vz/template/iso/ubuntu-24.04-server-cloudimg-amd64.img local-lvm qm set 9000 --scsihw virtio-scsi-pci --scsi0 local-lvm:vm-9000-disk-0 qm set 9000 --ide2 local-lvm:cloudinit qm set 9000 --boot c --bootdisk scsi0 qm set 9000 --serial0 socket --vga serial0 qm template 9000
Для більшості Linux-гостей цього досить. Якщо storage підтримує discard і ssd emulation, їх можна додати окремо. Але для старту це не обов’язково.
На linked clone легко зекономити місце, але повільний storage швидко покаже свої межі. Коли шаблон лежить на слабкому сховищі, усі клони відчують це одночасно. Саме тут Cloud-Init у Proxmox впирається вже не в конфіг, а в дискову модель вузла.
Як задати IP, gateway і DNS
Мережа задається через GUI на вкладці Cloud-Init або через qm set. Для статичної адреси треба передати IP з префіксом, gateway і за потреби DNS. Якщо шаблон зібраний коректно, гість отримає ці параметри на першому запуску без редагування netplan або /etc/network/interfaces.
Приклад для статичної IPv4-адреси:
qm set 9000 --ipconfig0 ip=192.168.10.50/24,gw=192.168.10.1 qm set 9000 --nameserver 192.168.10.1 qm set 9000 --searchdomain homelab.lan
Для DHCP достатньо такої опції:
qm set 9000 --ipconfig0 ip=dhcp
Де мережа ламається після першого старту
Часто cloud-init відпрацьовує коректно, але мережу рендерить інший стек. На Ubuntu це помітно, коли netplan є, але backend вказаний не той. На Debian іноді лишається старий файл інтерфейсів, який перекриває нову схему.
Ще одна типова проблема – інший інтерфейс усередині VM. Якщо шаблон створили з однією моделлю NIC, а в клона потім змінили її на іншу, ім’я інтерфейсу може змінитися. Адреса тоді не з’являється там, де її очікували.
Для тестових VM DHCP часто простіший. Статичні адреси варто залишати тим гостям, які прив’язані до firewall rules, reverse proxy або DNS-записів.
SSH-ключі, користувач і парольний вхід
SSH-ключі й користувач задаються на рівні шаблону або конкретного клону. Для homelab оптимальний варіант простий: передати public key, а пароль тримати тільки як аварійний доступ через консоль Proxmox.
У Proxmox це задається так:
qm set 9000 --ciuser admin qm set 9000 --sshkeys /root/.ssh/id_ed25519.pub
Якщо ключ треба вставити вручну, його додають через GUI в поле SSH public key. Для більшості Linux-гостей цього достатньо, якщо користувача створює сам cloud-init.
Що заважає входу по ключу
Найчастіша причина проста: у --sshkeys передали приватний ключ або файл у неправильному форматі. Друга проблема – в шаблоні вже був локальний користувач з іншим home-каталогом або іншими правами. Ключ тоді застосовується, але потрапляє не туди.
Обережніше з вимкненням парольного входу до перевірки SSH-ключа. Якщо мережа не піднялася або ключ не підхопився, доведеться відкривати консоль і лагодити шаблон вручну. Спочатку краще перевірити вхід, а вже потім закривати парольний доступ.
Клонування VM і межі linked clone
Готовий шаблон клонують як full clone або linked clone. Перший варіант створює окремий диск і краще підходить для довгих VM. Другий економить місце і створюється швидше, але залежить від базового шаблону та storage.
Клонування через CLI виглядає так:
qm clone 9000 110 --name debian-app-01 --full 1 qm set 110 --ipconfig0 ip=192.168.10.110/24,gw=192.168.10.1 qm set 110 --nameserver 192.168.10.1 qm set 110 --ciuser admin qm set 110 --sshkeys /root/.ssh/id_ed25519.pub qm start 110
Коли обирати full clone
Для тимчасових стендів linked clone доречний. Він швидко стартує і не роздуває storage. Але довгоживуча VM, активний запис на диск або перенесення між нодами швидко роблять таку економію незручною.
У homelab межа зазвичай проста: короткі експерименти ще нормально живуть як linked clone, а все, що переживе перший тиждень, краще відразу робити full clone. Інакше cleanup старих шаблонів починає вимагати зайвої перевірки залежностей.
| Варіант | Що дає | Де мінус |
|---|---|---|
| Full clone | Окремий диск, простіша міграція, менше залежностей | Більше місця і довше створення |
| Linked clone | Швидке клонування, менший розмір | Залежність від шаблону і чутливість до storage |
Як перевірити, що hostname, мережа і ключі застосувалися
Перевірка всередині гостя займає кілька хвилин. Треба подивитися статус cloud-init, журнали, мережу, hostname і наявність ключа в home-каталозі користувача. Якщо ці пункти збігаються, шаблон придатний для наступних клонів.
Усередині VM виконують:
cloud-init status --long cloud-init query ds hostnamectl ip a ip r cat /etc/resolv.conf getent passwd admin ls -la /home/admin/.ssh cat /home/admin/.ssh/authorized_keys journalctl -u cloud-init -b
На що дивитися в перевірці
cloud-init status --long має показати завершений стан без помилок. У cloud-init query ds має читатися правильний datasource. hostnamectl, ip a і ip r мають збігатися з параметрами клону.
Якщо користувач створився, але папка .ssh порожня, проблема майже завжди в ключі або правах каталогу. Якщо ключ на місці, а вхід не працює, далі вже варто дивитися sshd_config і локальні правила доступу.
Чому Cloud-Init у Proxmox ігнорує мережу або SSH-ключі
Типова причина – шаблон зроблений з невідповідного образу або вже містить старі локальні налаштування, які конфліктують з cloud-init. Другий клас проблем з’являється після змін самої VM: інший NIC, інший диск, інший користувач або ручне редагування мережевих файлів після першого успішного запуску.
Що ламається найчастіше
cloud-initне встановлений або його служби вимкнені.- Використано звичайний образ після ручної інсталяції замість cloud image.
- У шаблоні лишилися старі файли мережі, які перекривають нові дані.
- Ім’я мережевого інтерфейсу змінилося після заміни моделі NIC.
- Передано некоректний SSH public key або не той файл.
- Клон уже стартував з іншим набором параметрів, а потім його намагаються переробити без очистки стану.
Коли швидше перезібрати шаблон
Якщо шаблон уже обріс ручними правками, старими ключами, зміненими мережевими файлами й локальними обхідними рішеннями, ремонтувати його довго. Швидше взяти чистий cloud image, повторити імпорт і знову зробити template за тією ж схемою.
Ознака поламаного підходу проста: нова VM щоразу вимагає заходу в консоль і дрібного ручного виправлення. У такому стані шаблон уже не економить час. Для кількох стабільних образів Cloud-Init у Proxmox закриває стартовий етап надовго, але далі його межа проходить там, де вже треба розгортати ролі, секрети й сервіси окремими інструментами.
Коментарі
Коментарів ще немає. Обговорення - у Telegram.