Створення віртуальної машини (VM) у Proxmox VE — це швидкий процес через вбудований майстер. У цьому посібнику ми створимо VM з Ubuntu Server 24.04, але ті самі кроки застосовні до будь-якої ОС.
Крок 1: Завантаження ISO у сховище
Перед створенням VM потрібно завантажити ISO-образ. У вебінтерфейсі:
- Виберіть local (pve) → ISO Images
- Натисніть Upload або Download from URL
Або через командний рядок:
wget -P /var/lib/vz/template/iso/ https://releases.ubuntu.com/24.04/ubuntu-24.04-live-server-amd64.iso
Крок 2: Створення VM через вебінтерфейс
Натисніть Create VM у правому верхньому куті. Пройдіть по вкладках майстра:
| Вкладка | Параметр | Рекомендоване значення |
|---|---|---|
| General | VM ID / Name | 100 / ubuntu-server |
| OS | ISO Image | ubuntu-24.04-live-server.iso |
| OS | Guest OS Type | Linux / 6.x-2.6 Kernel |
| System | Machine / BIOS | q35 / OVMF (UEFI) |
| System | Add EFI Disk | Увімкнути |
| Disks | Bus / Storage | VirtIO SCSI / local-lvm |
| Disks | Disk size | 32 ГБ+ |
| CPU | Sockets / Cores | 1 / 2 |
| CPU | Type | host (для максимальної продуктивності) |
| Memory | RAM | 2048 МБ+ |
| Network | Bridge / Model | vmbr0 / VirtIO |
Крок 3: Створення VM через CLI (qm)
Для автоматизації використовуйте утиліту qm:
# Створити VM з ID 100
qm create 100 --name ubuntu-server --memory 2048 --cores 2 --net0 virtio,bridge=vmbr0 --cdrom local:iso/ubuntu-24.04-live-server-amd64.iso --scsihw virtio-scsi-pci --scsi0 local-lvm:32 --boot order=scsi0;ide2 --ostype l26
# Запустити VM
qm start 100
# Перегляд статусу
qm status 100
Крок 4: Налаштування QEMU Guest Agent
Guest Agent дозволяє Proxmox коректно завершувати роботу VM та отримувати IP-адресу гостя:
# Всередині Linux VM
apt install qemu-guest-agent -y
systemctl enable --now qemu-guest-agent
# У Proxmox: увімкнути в налаштуваннях VM
qm set 100 --agent 1
Корисні команди керування VM
# Список усіх VM
qm list
# Зупинити VM
qm stop 100
# Заморозити (suspend)
qm suspend 100
# Створити снапшот
qm snapshot 100 clean-install --description "Before updates"
# Відкотити снапшот
qm rollback 100 clean-install
# Видалити VM з усіма дисками
qm destroy 100 --purge
host дає максимальну продуктивність, але прив'язує VM до конкретного покоління заліза. За потреби живої міграції між різними хостами використовуйте x86-64-v2-AES.
Помилки під час створення і першого запуску VM
Три помилки, з якими найчастіше стикаються на етапі створення і першого старту — усі вони видно одразу у виведенні команди або в консолі VM, без потреби копирсатися в журналах.
TASK ERROR: unable to create VM 100 - VM 100 already exists
kvm: -device virtio-net-pci,...: Bus 'pci.0' not found
No bootable device -- press key to retry boot
- VM 100 already exists: ID вже зайнятий іншою VM або LXC-контейнером — нумерація спільна для
qmіpct. Перевіртеqm listіpct list, візьміть вільний ID черезpvesh get /cluster/nextid. - Bus 'pci.0' not found: конфігурація VM очікує Machine Type
q35, а фактично встановленоi440fx(або навпаки) після ручного редагування. Приведіть у відповідність:qm set 100 --machine q35. - No bootable device: ISO від'єднано від приводу або порядок завантаження не містить диск з образом. Перевірте
qm config 100 | grep bootі переконайтеся, щоide2з ISO вказано першим під час встановлення.
Перші дві помилки найчастіше виникають під час копіювання конфігурації між нодами або під час ручного редагування файлу VM у /etc/pve/qemu-server/ — після таких правок варто звіряти конфігурацію командою qm config перед запуском.
Коли стандартний майстер створення VM не підходить
Майстер зручний для однієї-двох машин, але не для всіх сценаріїв.
- Масове розгортання десятків однакових VM — швидше клонувати готовий шаблон через
qm clone, ніж проходити майстер для кожної машини окремо. - Імпорт готового диска з іншої платформи (VMware, Hyper-V) — використовуйте
qm importdisk, а не створення з нуля через інсталяційний ISO. - Автоматизація через Infrastructure as Code — для цього більше підходить Terraform-провайдер або прямі виклики API (
pvesh), а не ручний майстер у веб-інтерфейсі.
Перевірка результату
# Статус і IP-адреса VM (потрібен guest agent)
qm agent 100 network-get-interfaces
# Переконатися, що диск створено потрібного розміру
qm config 100 | grep scsi0
# Логи останнього запуску VM
journalctl -u qmeventd -n 20
Якщо агент повертає актуальну IP-адресу, а розмір диска в конфігурації збігається із заданим під час створення — VM налаштована коректно. Про масове розгортання через шаблони — у статті шаблони та Cloud-Init у Proxmox.
Часті питання
Чи обов'язково встановлювати QEMU Guest Agent, щоб віртуальна машина взагалі запустилась і працювала?
Ні, для запуску і звичайної роботи VM агент не обов'язковий — це додатковий компонент. Без нього Proxmox просто не зможе коректно завершувати роботу гостя з боку хоста і не покаже IP-адресу гостя у зведенні. Повсякденна робота машини не постраждає без агента: він покращує керування і моніторинг з боку Proxmox, а не саму гостьову ОС.
Чому IP-адреса гостя все ще не з'являється у зведенні Proxmox після встановлення пакета агента всередині VM?
Найімовірніше агент ще варто увімкнути в налаштуваннях обладнання самої VM, а не лише поставити пакет усередині гостя. Самого встановлення пакета замало — відповідну опцію в конфігурації віртуальної машини теж варто увімкнути, інакше Proxmox не встановить канал зв'язку, на який спирається агент, і зведення лишиться порожнім.
Чи можна збільшити розмір диска віртуальної машини вже після того, як її створено?
Так, диск уже створеної віртуальної машини збільшують пізніше просто на вкладці обладнання без перевстановлення гостя — збільшення не стирає наявні дані. Гостьовій операційній системі після цього все одно доведеться розпізнати і розширити власний розділ і файлову систему, оскільки Proxmox збільшує лише сам віртуальний диск, а не те, що всередині нього.
Якщо VM у майбутньому потрібно перенести на інший фізичний хост, чи важливий обраний під час створення тип CPU?
Так, вибір типу CPU host прив'язує віртуальну машину до конкретного набору можливостей саме цього процесора, що може завадити живій міграції на хост з іншим поколінням заліза. Більш загальний, сумісний тип CPU, обраний під час створення, зберігає можливість міграції у майбутньому, хоча і поступається типу host у піковій продуктивності.