Proxmox «QEMU завершився з кодом 1»: прочитайте помилку, знайдіть справжню причину

Що насправді означає «exit code 1» у Proxmox

Proxmox запускає ВМ, формуючи командний рядок QEMU, а потім передає його qemu-system-* (зазвичай через обгортку /usr/bin/kvm або безпосередньо) у контексті сервісу. Якщо QEMU відразу повертає 1, Proxmox виводить загальну банерну помилку «QEMU exited with code 1». Цей рядок — не провал; це епілог.

Думайте шарами: яка складова відмовила запуск?

• Рівень конфігурації: некоректний синтаксис конфігу ВМ, застарілі ключі, неможлива комбінація пристроїв, відсутній файл диску, невірний тип контролера, дублювання адрес PCI.
• Рівень прав/безпеки: відмова AppArmor/SELinux, невірна власність/дозволи на образи дисків, неможливість створити tap через привілеї.
• Рівень сховища: ZFS zvol зайнятий, невдача активації LVM‑thin, помилки mapper Ceph/RBD, застарілі дескриптори NFS, сесія iSCSI недоступна, таймаути локів.
• Рівень ядра/віртуалізації: відсутній KVM, відсутня вкладена віртуалізація, невідповідність CPU‑флагів, hugepages/NUMA заброньовані, але недоступні.
• Мережевий рівень: відсутній бридж, правила фаєрволу заважають tap, невідповідний MTU зазвичай не викликає помилку запуску, але помилки створення tap — так.
• Рівень ресурсів: немає ОЗП, бракує файлових дескрипторів, вичерпано inotify, ліміти процесів, нестача місця на накопичувачах для логів або стану.

Професійний підхід — знайти перший конкретний рядок помилки, який вивів QEMU. Все інше — театральна обгортка.

Цитата, яку варто тримати на стіні:

«Надія — це не стратегія.» — ген. Г. Норман Шварцкопф

Ви можете перезавантажити вузол і надіятись. А можна простежити відмову, виправити її одного разу і спати далі.

Швидкий план діагностики (перевірити 1/2/3)

1) Почніть із журналу для конкретного VMID і часової позначки

Якщо ви робите тільки одну річ: зафіксуйте рядок логу перед тим, як QEMU помер.

• Шукайте: «cannot open», «Permission denied», «Device or resource busy», «failed to get», «could not set up», «lock timeout», «invalid argument».
• Рішення: якщо помилка називає файл/шлях/пристрій — ви в зоні сховища/прав. Якщо вона називає bridge/tap — це мережа. Якщо згадується KVM, CPU або accel — це рівень ядра/віртуалізації.

2) Підтвердіть, чи існує застарілий лок або зомбі‑процес QEMU

Proxmox має механізм локів; у QEMU свій життєвий цикл PID; бекенди сховищ іноді тримають пристрої «зайнятими» після збою.

• Шукайте: наявність lock file, коли qm list показує запущені ВМ, хоча насправді ні, старий qemu-system-x86_64 ще живий, ZFS zvol утримується відкритим.
• Рішення: якщо є застарілий лок — обережно зніміть його (після підтвердження, що ВМ дійсно не працює). Якщо існує процес QEMU, не запускайте другий; коректно вбийте потрібний PID і приберіть наслідки.

3) Перевірте, чи здоровий бекенд, від якого залежить ВМ (сховище + мережа)

«Код 1» часто означає, що конфігурація ВМ нормальна, а світ під нею — ні.

• Сховище: перевірте стан пулу, thinpool, стан Ceph, монтування NFS, вільне місце/іноди.
• Мережа: перевірте існування bridge, роботу створення tap, чи фаєрвол не ламає скрипти.
• Рішення: якщо бекенд деградований — спочатку виправте бекенд. Запуск ВМ на пошкодженому підґрунті перетворює інцидент на зміну кар’єри.

Жарт №1: Код виходу 1 — це QEMU, яке каже «Я не злий, я просто розчарований.»

Де живе справжня помилка: логи та процеси

Шари Proxmox, що дають підказки

• pvedaemon / pveproxy: логи UI‑задач, помилки API, контекст автентифікації.
• qemu-server: формує командний рядок QEMU; логує, чому відмовився продовжувати.
• systemd + journald: канонічна хронологія; показує stderr QEMU, помилки tap, відмови в правах.
• стек сховища: ZFS, LVM, Ceph, NFS, iSCSI, multipath; у кожного свої логи та команди.
• кільце ядра: відмови KVM, I/O‑помилки, VFIO, відмови AppArmor, проблеми з bridge.

Як читати лог завдання Proxmox як дорослий

«Переглядач завдань» в UI зручний для часових міток і високорівневих повідомлень. Проблема в тому, що він часто обрізає точний рядок stderr QEMU, який вам потрібен. Сприймайте його як індекс, а не як джерело істини. Коли бачите «QEMU exited with code 1», негайно переходьте до journalctl і конфігу ВМ та об’єктів сховища.

Що ви шукаєте

Вам потрібен перший рядок помилки, який вказує ресурс. Приклади «хороших» помилок:

• could not open disk image /dev/zvol/rpool/data/vm-101-disk-0: Device or resource busy
• failed to create tun device: Operation not permitted
• kvm: failed to initialize: No such file or directory
• Cannot access storage 'ceph-rbd' (500)
• unable to parse value of 'net0'

«Погані» помилки — це загальні обгортки. Ігноруйте їх. Прокручуйте вгору.

Практичні завдання: команди, виводи, рішення (12+)

Все нижче розраховано на запуск на вузлі Proxmox із типовими пакетами. Замініть 101 на ваш VMID та підлаштуйте імена сховищ.

Завдання 1: Витягніть останню спробу старту ВМ з journald

cr0x@server:~$ journalctl -u pvedaemon -u pveproxy -u pvescheduler --since "15 min ago" | tail -n 120
Dec 26 10:21:33 pve01 pvedaemon[2214]: starting task UPID:pve01:00005A2B:0001B8F2:676D1E5D:qmstart:101:root@pam:
Dec 26 10:21:34 pve01 pvedaemon[2214]: VM 101 qmp command failed - got timeout
Dec 26 10:21:34 pve01 pvedaemon[2214]: VM 101 - unable to open disk image '/dev/zvol/rpool/data/vm-101-disk-0': Device or resource busy
Dec 26 10:21:34 pve01 pvedaemon[2214]: VM 101 - QEMU exited with code 1

Що це означає: у вас є конкретний ресурс: шлях zvol зайнятий. Це сховище, а не «Proxmox поводиться дивно».

Рішення: припиніть дивитись на конфіг ВМ; дослідіть, хто тримає zvol відкритим (Завдання 7) і чи напівзапущена ВМ (Завдання 2).

Завдання 2: Перевірте, чи Proxmox вважає ВМ запущеною і чи існує PID QEMU

cr0x@server:~$ qm status 101
status: stopped

cr0x@server:~$ pgrep -a -f "qemu-system.*-id 101"

Що це означає: якщо qm status каже stopped, але ви все ще бачите процес QEMU, у вас застарілий стан або попередня спроба запуску не завершилася коректно.

Рішення: якщо QEMU існує, проінспектуйте його (Завдання 3) і зупиніть коректно або вбийте після підтвердження, що це правильний PID.

Завдання 3: Перевірте точний командний рядок QEMU, який Proxmox намагався запустити

cr0x@server:~$ qm showcmd 101 --pretty
/usr/bin/kvm \
  -id 101 \
  -name 'app-prod-01,debug-threads=on' \
  -machine type=pc-q35-8.1+pve0 \
  -m 8192 \
  -smp 4,sockets=1,cores=4,maxcpus=4 \
  -drive if=none,id=drive-scsi0,format=raw,file=/dev/zvol/rpool/data/vm-101-disk-0,cache=none,aio=io_uring,discard=on \
  -device virtio-scsi-pci,id=scsihw0,bus=pci.0,addr=0x5 \
  -netdev tap,id=net0,ifname=tap101i0,script=/var/lib/qemu-server/pve-bridge,downscript=/var/lib/qemu-server/pve-bridgedown,vhost=on \
  -device virtio-net-pci,mac=BC:24:11:AA:BB:CC,netdev=net0,bus=pci.0,addr=0x12 \
  ...

Що це означає: тепер ви можете відтворити або логічно розібратись у причинах відмов: шлях до диска, режим кешу, бекенд aio, тип машини, налаштування netdev.

Рішення: якщо якась опція підозріла (наприклад, aio=io_uring на старому ядрі), у вас є конкретний експеримент: змінити одну річ і повторити.

Завдання 4: Прочитайте конфіг ВМ на предмет помилок парсингу та дрейфу

cr0x@server:~$ cat /etc/pve/qemu-server/101.conf
boot: order=scsi0;net0
cores: 4
memory: 8192
name: app-prod-01
net0: virtio=BC:24:11:AA:BB:CC,bridge=vmbr0,firewall=1
scsi0: rpool:vm-101-disk-0,discard=on,cache=none,aio=io_uring
scsihw: virtio-scsi-pci

Що це означає: конфіг зберігається в pmxcfs і має бути узгодженим у кластері. Дрібні опечатки (особливо в рядках args:) можуть жорстко призвести до помилки QEMU.

Рішення: якщо бачите ручні екзотичні налаштування, плануйте тимчасово повернутися до дефолтів, щоб ізолювати проблему.

Завдання 5: Підпильнуйте логи qemu-server для VMID

cr0x@server:~$ journalctl -t pve-qemu-server -S "30 min ago" | grep -E "VM 101|101" | tail -n 80
Dec 26 10:21:34 pve01 pve-qemu-server[58312]: VM 101 - start failed: unable to open disk image '/dev/zvol/rpool/data/vm-101-disk-0': Device or resource busy
Dec 26 10:21:34 pve01 pve-qemu-server[58312]: VM 101 - failed to run /usr/bin/kvm: exit code 1

Що це означає: підтверджує, що це QEMU відмовився, а не баг планувальника або проблема автентифікації API.

Рішення: переходьте до розслідування рівня сховища (Завдання 6–9).

Завдання 6: Перевірте стан пулу ZFS і недавні помилки

cr0x@server:~$ zpool status -x
all pools are healthy

cr0x@server:~$ zpool status rpool
  pool: rpool
 state: ONLINE
status: Some supported features are not enabled on the pool.
action: Enable all features using 'zpool upgrade'. Once this is done,
	the pool may no longer be accessible by software that does not support the features.
  scan: scrub repaired 0B in 00:12:41 with 0 errors on Thu Dec 26 09:10:05 2025
config:

	NAME        STATE     READ WRITE CKSUM
	rpool       ONLINE       0     0     0
	  nvme0n1   ONLINE       0     0     0

errors: No known data errors

Що це означає: якщо ви бачите помилки читання/запису/контрольних сум — ваш «код 1» може бути першим симптомом флюктуацій сховища. Якщо пул здоровий — шукайте утримувачі zvol/локи.

Рішення: якщо пул деградований — припиніть спроби запуску ВМ і виправте пул (замінити диск, resilver, scrub).

Завдання 7: Знайдіть процес, який утримує zvol або блочний пристрій відкритим

cr0x@server:~$ ls -l /dev/zvol/rpool/data/vm-101-disk-0
lrwxrwxrwx 1 root root 10 Dec 26 10:20 /dev/zvol/rpool/data/vm-101-disk-0 -> ../../zd16

cr0x@server:~$ lsof /dev/zd16 | head
COMMAND    PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
qemu-syst 4121 root   15u   BLK  230,16      0t0  123 /dev/zd16

Що це означає: диск зайнятий, бо процес QEMU вже має його відкритим. Це може бути попередня інстанція ВМ, задача бекапу або застрягла міграція.

Рішення: проінспектуйте PID 4121, підтвердіть, що його безпечно завершити, потім коректно зупиніть його (Завдання 8). Не видаляйте локи навмання, поки не зрозумієте, хто утримує пристрій.

Завдання 8: Зупиніть завислий процес ВМ (спочатку коректно, потім силоміць)

cr0x@server:~$ qm stop 101
trying to stop VM 101...
VM 101 stopped

cr0x@server:~$ kill -TERM 4121

cr0x@server:~$ sleep 2; ps -p 4121 -o pid,cmd
  PID CMD

Що це означає: якщо процес зникає після TERM — добре. Якщо лишається, можливо він застряг у некерованому I/O (стан D), що повертає нас до сховища.

Рішення: якщо процес у стані D, не паліть kill -9 і не вважайте проблему вирішеною. Дослідіть шлях I/O (NFS/iSCSI/Ceph). Якщо це звичайний завислий процес, контрольоване вбивство може бути прийнятним після валідації.

Завдання 9: Перевірте локи ВМ у Proxmox і безпечно їх приберіть

cr0x@server:~$ qm config 101 | grep -i lock
lock: backup

cr0x@server:~$ qm unlock 101
unlocking VM 101

Що це означає: Proxmox може блокувати ВМ під час бекапу, міграції, знімка тощо. Якщо лок лишається після збою, старти можуть провалюватись або поводитись передбачувано.

Рішення: розблокуйте тільки після підтвердження, що пов’язана операція дійсно не виконується (перевірте логи бекапу, поточні задачі і процеси). Розблокування під час бекапу веде до часткових снапшотів і складних розмов.

Завдання 10: Підтвердіть вільне місце та іноди сховища

cr0x@server:~$ df -hT /var/lib/vz /var/log
Filesystem     Type  Size  Used Avail Use% Mounted on
rpool/ROOT/pve-1 zfs   96G   74G   22G  78% /
rpool/var-log    zfs   10G  9.8G  256M  98% /var/log

cr0x@server:~$ df -i /var/log
Filesystem     Inodes IUsed IFree IUse% Mounted on
rpool/var-log  524288 11234 513054    3% /var/log

Що це означає: майже повний /var/log (або root fs) може призвести до того, що QEMU не зможе записати стан, логи або сокети. Іноди також важливі, особливо на ext4‑підкладках.

Рішення: якщо використання високе — ротація логів, розширення датасетів або переміщення галасливих сервісів. Не видаляйте «випадкові логи», якщо не хочете втратити свідчення, які потрібні для розслідування.

Завдання 11: Перевірте доступність KVM і чи увімкнена віртуалізація

cr0x@server:~$ ls -l /dev/kvm
crw-rw---- 1 root kvm 10, 232 Dec 26 08:02 /dev/kvm

cr0x@server:~$ kvm-ok
INFO: /dev/kvm exists
KVM acceleration can be used

cr0x@server:~$ dmesg | tail -n 20
[  112.345678] kvm: VMX supported
[  112.345689] kvm: Nested virtualization enabled

Що це означає: відсутній /dev/kvm або відмови тут можуть призвести до раннього виходу QEMU, іноді з хибними повідомленнями. На деяких системах QEMU все одно може працювати без KVM, але конфіги Proxmox можуть очікувати функцій KVM.

Рішення: якщо KVM недоступний — перевірте BIOS/UEFI VT‑x/AMD‑V, модулі ядра (kvm_intel/kvm_amd) і чи ви запущені всередині гіпервізора без вкладеної віртуалізації.

Завдання 12: Шукайте відмови AppArmor, що блокують QEMU

cr0x@server:~$ journalctl -k --since "30 min ago" | grep -i apparmor | tail -n 20
Dec 26 10:21:34 pve01 kernel: audit: type=1400 apparmor="DENIED" operation="open" profile="pve-qemu-kvm" name="/mnt/pve/nfs-share/images/101/vm-101-disk-0.qcow2" pid=58345 comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=0 ouid=0

Що це означає: QEMU блокується профілем безпеки при спробі відкрити образ диска. Це чистий корінь проблеми.

Рішення: виправте шлях сховища та очікування профілю AppArmor (зазвичай переконайтесь, що сховище налаштоване через Proxmox, змонтоване під правильним шляхом, а не як довільний mount), або налаштуйте політику, якщо точно знаєте, що робите.

Завдання 13: Підтвердіть умови для створення bridge та tap

cr0x@server:~$ ip link show vmbr0
4: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 5a:1e:4c:00:11:22 brd ff:ff:ff:ff:ff:ff

cr0x@server:~$ ip tuntap show | head
tap101i0: tap persist vnet_hdr

Що це означає: відсутність vmbr0 або неможливість створити tap пристрій можуть спричинити миттєвий вихід QEMU. Якщо tap101i0 вже існує несподівано, це може бути залишковий інтерфейс після невдалого старту.

Рішення: якщо бридж відсутній — виправте мережу хоста. Якщо tap існує але ВМ зупинена — обережно видаліть застарілий tap після підтвердження, що жоден процес ним не користується.

Завдання 14: Перевірте невдачу активації сховища LVM‑thin

cr0x@server:~$ lvs -a -o +devices
  LV               VG  Attr       LSize   Pool Origin Data%  Meta%  Devices
  pve/data         pve twi-aotz--  <1.82t             78.12  2.34   /dev/sda3(0)
  vm-101-disk-0    pve Vwi-a-tz--   64.00g data       91.02          /dev/sda3(12345)

cr0x@server:~$ lvchange -ay pve/vm-101-disk-0
  1 logical volume(s) in volume group "pve" now active

Що це означає: якщо активація не вдалася або thinpool заповнений, QEMU не зможе відкрити блочний пристрій. Тонке виділення може обманювати, поки не стане критично.

Рішення: якщо thinpool близький до 100% або метадані вичерпані — потрібно звільнити місце або розширити пул перед подальшими стартами.

Типові підозрювані: шаблони відмов і як їх довести

1) Проблеми зі шляхом сховища: «cannot open …» майже завжди буквально

Коли QEMU не може відкрити диск — він виходить. Нема диска — нема ВМ. Причини включають:

• ZFS zvol, утримуваний застарілим процесом
• NFS stale file handle після відмови/перемикання сервера
• невдача мапінгу Ceph/RBD або невідповідність автентифікації
• LVM‑thin без вільного місця або повні метадані
• невірні дозволи у директорії, де змонтовано сховище

Доведіть це, перевіривши: точний шлях у qm showcmd, існування пристрою/файлу та здоров’я бекенду (команди ZFS/LVM/Ceph/NFS).

2) Блокування і конкурентність: Proxmox захищає вас… поки ні

Proxmox використовує локацію, щоб уникнути одночасних операцій над ВМ (бекап + запуск, знімок + міграція тощо). Після крашей або збійних задач локи можуть залишатись.

Доведіть це, прочитавши конфіг ВМ на наявність рядка lock: і перевіривши поточні задачі в журналі. Видаляйте локацію тільки коли впевнені, що пов’язана операція завершена.

3) Налаштування мережі: збої tap/bridge вбивають ВМ на початку

Якщо QEMU не може створити або приєднати tap‑інтерфейс — він виходить з кодом 1. Часті причини: відсутній бридж, некоректний синтаксис /etc/network/interfaces, збої скриптів фаєрволу або проблеми з привілеями/способностями.

Доведіть це, перевіривши ip link show, наявність vmbrX і журнали journald з повідомленнями про tap, tun, bridge або vhost.

4) Функції ядра та акселератори: KVM, VFIO, hugepages

QEMU гнучкий, але типові конфіги Proxmox очікують KVM і певні CPU‑флаги. При passthrough GPU (VFIO) режими збільшують кількість причин відмов: групи IOMMU, проблеми скидання пристрою, дозволи на /dev/vfio/*, проблеми ROM.

Доведіть це, зіставивши рядки stderr QEMU з повідомленнями ядра (journalctl -k, dmesg) і перевіривши, чи існують пристрої та чи зв’язані вони з правильним драйвером.

5) «Оптимізаційні» прапори, що кусають: AIO‑бекенди, режими кешу, discard

Опції на кшталт aio=io_uring і агресивні режими кешу можуть бути чудовими — поки не зустрінуть старе ядро, дивний файловий шар або бекенд, що не підтримує запитане. Тоді QEMU виходить миттєво, і ви сперечаєтесь з рядком конфігу, який хтось скопіпастив із бенчмарк‑блога.

Жарт №2: Нічого не є більш постійним, ніж «тимчасове» налаштування продуктивності, додане в п’ятницю.

Три корпоративні міні‑історії (помилки, боком, нудні перемоги)

Інцидент №1: Неправильне припущення (і лок, який не був проблемою)

Середня компанія тримала кластер Proxmox для внутрішніх сервісів. Одного ранку критична ВМ не захотіла стартувати: «QEMU exited with code 1». Інженер на виклику побачив lock: backup у конфігу ВМ і зробив очевидний висновок: застарілий лок. Він виконав qm unlock, а потім кілька разів натискав «Start» у UI, бо UI був під рукою, а нетерплячість — відновлюване джерело енергії.

Це не спрацювало. Тепер ситуація стала гіршою: вони зняли легітимний лок, поки на NFS‑сервері ще працювала задача створення снапшоту від команди збереження даних. Та операція не була видима як задача Proxmox, бо її тригерили скрипти storage‑команди. QEMU відмовлявся, бо qcow2 файл тимчасово блокувався на NFS і повертав неконсистентні метадані під час вікна снапшоту.

«Код 1» був останнім доміно. Справжній підказкою були рядки ядра: переривчасті «stale file handle» та таймаути NFS під час спроб старту. Але ці рядки ніколи не перевіряли, бо теорія про лок здавалася акуратною.

Виправлення було нудним: не намагатися стартувати ВМ під час вікна снапшоту сховища, змонтувати NFS з адекватними опціями для їхнього середовища і додати пре‑флайт‑перевірку в операційні рукописи: перевіряти, що бекенд сховища не в обслуговуванні перед очищенням локів. Також змінили політику: локи Proxmox знімаються тільки після підтвердження, що пов’язана операція не виконується ніде в стеку.

Пізніше команда додала невеликий скрипт, який друкує «сигнали готовності сховища» (відповідь NFS, стан Ceph, стан ZFS) паралельно з діями старту ВМ. Це не запобігло всім інцидентам, але запобігло повторенню саме цього, що і є справжнім KPI.

Інцидент №2: Оптимізація, що відплатилася (io_uring зустрів реальність)

Інша організація хотіла кращої продуктивності дисків для бази даних. Хтось прочитав, що io_uring — майбутнє, і розгорнув aio=io_uring і деякі налаштування кешу через автоматизацію по флоту ВМ. Зміна виглядала безпечним: один параметр у кожному конфігу ВМ.

Через тиждень, після відкладеного оновлення ядра на частині вузлів, міграція опинила ВМ на старішому вузлі. ВМ почала падати з «QEMU exited with code 1». У логах задач було «invalid argument» навколо визначення диску. Це не було очевидно, бо ВМ запускалась нормально на інших вузлах.

Корінь: старіший набір ядро/QEMU не підтримував обраний AIO‑бекенд для того шляху сховища. Параметр був дійсний на нових білдах, але ніс сенсу на старих. Кластер став мінним полем сумісності: конфіги ВМ очікували функцій, яких не було на всіх вузлах.

Виправлення не полягало в відмові від тюнінгу продуктивності. Воно полягало в тому, щоб припинити удавати, що кластер однорідний. Вони ввели базові вимоги до версій вузлів, додали перевірку CI, яка відхиляє зміни конфігів, що вимагають непідтримуваних функцій на будь‑якому вузлі кластеру, і обмежили оптимізацію лише на вузлах із міткою «known‑good». Продуктивність збереглася. Несподівані відмови — ні. Урок: оптимізуйте так, ніби ви будете на виклику для крайових випадків.

Інцидент №3: Нудна практика, що врятувала день (дисципліна журналів)

Третя команда мала політику: кожен невдалий старт ВМ потрібно діагностувати через логи перед будь‑яким перезапуском. Звучало педантично. І було таким, але в хорошому сенсі.

Під час відключення живлення один вузол повернувся з трохи іншою мережею. Кілька ВМ не стартували з «QEMU exited with code 1». Люди були готові перезавантажити вузол знову, думаючи, що «бриджі не піднялись».

На виклику дотримались політики: journalctl -t pve-qemu-server плюс journalctl -k. Помилка була чіткою: створення tap не вдалось через досягнення користувацького ліміту процесів у дивному випадку, спричиненому агентом моніторингу, що форкався під час стартапу. Перезавантаження вузла замаскувало б проблему тимчасово і забезпечило повторення.

Вони підняли відповідні ліміти systemd, виправили конфіг агента моніторингу і перезапустили лише постраждалі сервіси. ВМ запустились, інцидент закрився, і команда не додала «перезавантажити знову» до рукопису.

Нудна практика — трактування журналів як первинних доказів — запобігла циклу здогадок. Це також породило чистий інцидент‑репорт з реальним коренем. Аудитори це люблять. Інженери, що сплять — теж.

Поширені помилки: симптом → корінь → виправлення

1) Симптом: «Device or resource busy» на zvol або диску

Корінь: старий процес QEMU все ще тримає пристрій відкритим; процес бекапу/міграції його утримує; ядро застрягло в I/O.

Виправлення: знайдіть утримувача за допомогою lsof / fuser, зупиніть ВМ або проблемний процес, потім повторіть спробу. Якщо утримувач у стані D — дослідіть бекенд сховища (NFS/Ceph/iSCSI), а не бавтесь у whack‑a‑mole з PID.

2) Симптом: «Permission denied» при відкритті образу на директорійному сховищі

Корінь: невірні дозволи/власність на шляху образу; сховище змонтовано поза очікуваними шляхами Proxmox; відмова AppArmor.

Виправлення: переконайтесь, що сховище налаштоване через Proxmox, перевірте точку монтування (/mnt/pve/<storage>), виправте права файлів, перевірте відмови AppArmor і уніфікуйте шляхи.

3) Симптом: «could not create tap device» / «Operation not permitted»

Корінь: відсутній бридж, скрипти фаєрволу аварійно завершуються, змінені можливості або залишковий tap інтерфейс викликає колізії.

Виправлення: перевірте, що vmbr0 існує і UP; перегляньте логи фаєрволу; видаліть застарілий tap тільки після перевірки, що жоден процес його не використовує; обережно перезавантажте мережеві налаштування.

4) Симптом: старт не вдається тільки на одному вузлі

Корінь: дрейф вузла: різні версії ядра/QEMU, відсутні CPU‑флаги, різниця в доступі до сховища, застарілі монтування, зломаний multipath.

Виправлення: порівняйте версії вузлів і ключові конфіги, уніфікуйте пакети, перевірте доступ до сховища з цього вузла і уникайте прапорів конфігу, що вимагають нових фіч, якщо кластер неоднорідний.

5) Симптом: «kvm: failed to initialize» або «failed to get KVM»

Корінь: віртуалізація вимкнена в BIOS/UEFI, відсутні модулі ядра, ви запускаєтесь у VM без вкладеної віртуалізації, або проблеми з правами на /dev/kvm.

Виправлення: увімкніть VT‑x/AMD‑V, підвантажте модулі, переконайтесь, що вкладена віртуалізація дозволена зверху, перевірте власність/групу /dev/kvm.

6) Симптом: «Cannot access storage … (500)»

Корінь: помилка плагіна сховища Proxmox: недоступний NFS/Ceph target, проблеми автентифікації, застаріле монтування, відсутні keyring’и.

Виправлення: переконайтесь, що сховище онлайн з цього вузла (стан mount, стан Ceph), виправте автентифікацію, перемонтуйте і тільки потім повторіть запуск ВМ.

7) Симптом: «invalid argument» в опціях drive/net

Корінь: несумісна опція QEMU для версії QEMU на вузлі; поганий рядок args:; непідтримуваний AIO/cache для бекенду.

Виправлення: спростіть: приберіть кастомні args, поверніться до дефолтів, потім додавайте зміни по одній. Уніфікуйте версії QEMU по вузлах.

8) Симптом: ВМ стартує з CLI, але не через UI/API задачі

Корінь: різниця в контексті дозволів, змінні оточення або hook‑скрипти (фаєрвол, пре‑старти) що падають.

Виправлення: відтворіть через qm start і подивіться логи задач; перевірте hook‑скрипти і фаєрвол; переконайтесь, що використовується той самий користувацький контекст.

Контрольні списки / покроковий план

Покроково: від «code 1» до кореня менш ніж за 10 хвилин

1. Захопіть часову мітку невдалого старту (лог UI підходить).
2. Витягніть рядки journald навколо того часу для pve-qemu-server і повідомлень ядра. Знайдіть перший конкретний рядок помилки.
3. Запустіть qm showcmd для ВМ і знайдіть шляхи дисків, netdev‑конфіг та незвичні опції.
4. Перевірте статус локів ВМ в конфігу; розблокуйте лише після підтвердження, що пов’язана операція не виконується.
5. Перевірте здоров’я бекенду:
   • ZFS: zpool status
   • LVM: lvs і використання пулу
   • Ceph: стан кластера і основи мапінгу RBD
   • NFS: швидкість монтування і помилки ядра
6. Шукайте залишки: існуючий PID QEMU, застарілий tap інтерфейс, утримувач zvol.
7. Вносьте одну зміну за раз, повторюйте спробу і негайно перевіряйте логи.

Чекліст: спочатку сховище, бо воно ламає найдорожче

• Шлях до диска існує і доступний із вузла, що стартує ВМ.
• Жоден процес не тримає блочний пристрій/файл образу відкритим несподівано.
• Стан пулу OK (немає деградованих vdev, немає помилок читання/запису).
• Вільне місце в порядку, включно з метаданими thinpool і розділами root/log.
• Немає застарілих NFS handles або проблем iSCSI у логах ядра.

Чекліст: мережна простота

• Бридж існує і UP (ip link show vmbr0).
• Tap‑пристрої створюються/видаляються коректно; немає колізій імен.
• Скрипти фаєрволу не падають (помилки в journald).

Чекліст: сумісність версій і функцій

• Версії QEMU узгоджені між вузлами кластера, або конфіги ВМ уникають вузько вузлових фіч.
• KVM доступний і увімкнений (/dev/kvm існує, модулі підвантажені).
• При passthrough пристрої прив’язані правильно (VFIO/IOMMU), якщо використовуються.

Цікаві факти та історичний контекст (речі, що допомагають дебагу)

1. QEMU почався в 2003 році як швидкий емулятор процесора і виріс у стандартний інструмент віртуалізації в Linux.
2. KVM з’явився в ядрі Linux у 2007, перетворивши QEMU з «чистої емуляції» в апаратно‑прискорену віртуалізацію на x86.
3. Конфіги ВМ Proxmox живуть у кластерній файловій системі (pmxcfs) під /etc/pve, тому правки реплікуються і спліт‑брейн болісний.
4. Код виходу 1 навмисне загальний: QEMU часто використовує його для «failed to initialize or parse arguments», що може означати відсутній диск або непідтримувану опцію.
5. Virtio пристрої з’явились, бо емуляція реального обладнання дорога: virtio — паравіртуальний інтерфейс, що зменшує накладні витрати і підвищує продуктивність.
6. io_uring став мейнстрімом у Linux близько 2019+ і продовжує еволюціонувати; змішування ядер і версій QEMU може зробити «допустимі» опції недопустимими на деяких вузлах.
7. ZFS zvol — це блочні пристрої, підкріплені датасетами, і вони можуть бути «зайнятими» через утримувачів, яких ви не побачите у UI Proxmox — треба інструменти на рівні процесів.
8. LVM‑thin може overcommit’итися, що класно, поки не стане ні — умови вичерпання проявляються дивними збоями ВМ, а не дружніми попередженнями.
9. Tap‑пристрої — це функція ядра Linux, і відмови при їх створенні зазвичай пов’язані з правами/способностями, а не «помилкою Proxmox».

FAQ

Чому Proxmox показує тільки «QEMU exited with code 1»?

Тому що Proxmox відображає статус виходу QEMU, а не деталі stderr. Дієва помилка зазвичай у journald під pve-qemu-server або в логах ядра.

Де найкраще знайти реальний рядок помилки?

journalctl -t pve-qemu-server навколо часової позначки старту, плюс journalctl -k для відмов ядра і проблем з пристроями.

Чи безпечно виконувати qm unlock коли ВМ не стартує?

Ні. Розблоковувати можна тільки після доведення, що пов’язана операція (бекап/міграція/снапшот) ніде не виконується. Інакше ризикуєте корупцією або неконсистентними снапшотами.

Моя ВМ стартує на вузлі A, але падає на вузлі B. Що підозрювати спочатку?

Дрейф вузла: різні версії QEMU/ядра, відмінності в доступі до сховища (монтування відсутнє на вузлі B) або різні політики безпеки. Порівняйте вихід qm showcmd і перевірте доступність сховища з вузла B.

Чи може майже повний /var/log або root filesystem спричинити невдачу старту QEMU?

Так. QEMU і Proxmox мають потребу писати логи, сокети і runtime‑стан. Повний файловий простір може проявитись як дивні відмови старту, іноді все ще повідомлені як «code 1».

Чи означає «Device or resource busy» завжди працюючу ВМ?

Часто — так, але не завжди. Це може бути процес бекапу, застряглий екземпляр QEMU або блокування на стороні сховища (особливо на NFS/Ceph). Використовуйте lsof/fuser, щоб довести це.

Як безпечно відтворити відмову без гадань?

Використайте qm showcmd <vmid> щоб побачити точний командний рядок QEMU, потім сфокусуйтесь на ресурсі, що фейлиться в логах (шлях диска, tap інтерфейс, KVM). Не ходіть випадковими змінами в конфігу.

Чи добра ідея додавати кастомні args: у конфіги Proxmox?

Тільки якщо ви готові до операційного тягаря: сумісність вузлів, тестування оновлень і майбутні нічні розбірки проблем. Дефолти існують не просто так.

Який найшвидший спосіб зрозуміти, storage vs networking vs KVM?

Читайте перший конкретний рядок помилки. Помилки шляху диска — на сховище. Помилки tap/bridge — на мережу. Помилки KVM/VFIO — на ядро/віртуалізацію.

Висновок: практичні подальші кроки

Коли Proxmox каже «QEMU exited with code 1», не сприймайте це як загадку. Сприйміть це як вказівку на докази, які ви ще не зібрали. Ваше завдання — витягти перший конкретний рядок помилки і валідувати підсистему, яку він називає.

Наступні кроки, які ви можете зробити сьогодні:

• Уніфікуйте runbook: журнал першочергово, потім локи/процеси, потім здоров’я бекенду.
• Зменшіть дрейф кластера: вирівняйте версії ядра/QEMU по вузлах або обмежте фічі ВМ.
• Аудитуйте «покращення продуктивності» у конфігах ВМ і прибирайте те, що не можна обґрунтувати під час інциденту.
• Введіть звичку: кожен «code 1» отримує запис з коренем причини. Не тимчасове рішення. Саме запис.

Якщо ви робитимете це послідовно, «QEMU exited with code 1» перестане бути інцидентом і стане рутинним діагностичним кроком. Саме там йому й місце.