Proxmox «VM disk vanished»: сховище проти конфігурації і як діагностувати

Єдина модель мислення, яка вам потрібна: вказівники конфігурації проти об’єктів сховища

Коли Proxmox повідомляє, що диск ВМ відсутній, ви маєте справу з двома шарами, які можуть розсинхронізуватися:

• Шар конфігурації: конфігурація VM у /etc/pve/qemu-server/<vmid>.conf (і визначення сховищ у /etc/pve/storage.cfg). Це «система вказівників»: яке ім’я диска, який ID сховища, який ідентифікатор тому.
• Шар сховища: фактичні об’єкти на бекенді сховища (ZFS zvol, LVM LV, файл QCOW2, образ Ceph RBD, iSCSI LUN, файл на NFS). Це «фізика».

Більшість інцидентів «vanished disk» — це одне з наступного:

1. Об’єкт існує, вказівник неправильний (невідповідність конфігурації). Це щасливий випадок: виправте конфіг, імпортуйте том, оновіть сховище, перезапустіть VM.
2. Вказівник вірний, але об’єкт недоступний (сховище впало, пул не імпортовано, мережевий шлях недоступний, проблеми з правами). Зазвичай відновлюване без втрати даних, але тут треба припинити вгадувати й почати доводити.
3. Об’єкт зник (том видалено, скасовано снапшот, замінено сховище, неправильний пул). Це вже історія з відновленням з резервних копій або глибоким відновленням сховища.

Отже, ваша задача не «змусити Proxmox перестати скаржитися». Ваша задача — відповісти з доказами на такі питання:

• Який ідентифікатор тому Proxmox вважає використаним для цієї ВМ?
• Чи існує цей том на бекенді?
• Якщо ні — чи існує схожий том десь ще?
• Чи змінювався storage.cfg, чи змінився ID сховища, чи перемістився бекенд?

Цитата, яка добре старіє в операціях: «парафразована ідея» — Gene Kim: надійність походить з побудови зворотних зв’язків, які ловлять помилки рано, а не з героїчних дій після факту. Сенс тут: привчіться перевіряти конфіг та сховище окремо.

Невеликий жарт: Ваш диск ВМ не «зник»; він просто поїхав жити на ферму разом з іншими загубленими LUN.

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

Це план дій, який ви використовуєте, коли люди чекають. Він орієнтований на швидкість і докази.

Перший: доведіть, що Proxmox вважає, що має існувати

1. Знайдіть конфіг ВМ, прочитайте рядки з дисками (virtio/scsi/sata/ide). Витягніть ідентифікатори томів.
2. Перевірте, чи визначено згаданий storage ID і чи він зараз «активний».
3. Спробуйте пошук тому на рівні Proxmox (pvesm list / pvesm status).

Другий: доведіть, чи існує об’єкт на бекенді

1. ZFS: перерахувати zvol/dataset, підтвердити, що пул імпортовано і він здоровий.
2. LVM-thin: перерахувати LV, переконатися, що VG присутній і thinpool активний.
3. Директорійне сховище: перевірити шляхи файлів і права, підтвердити, що монтування реальне (не порожня точка монтування).
4. Ceph: перерахувати образи RBD, перевірити стан кластера і аутентифікацію keyring.

Третій: оберіть найнадійніший шлях відновлення

• Якщо диск існує, але вказівник неправильний: змініть конфіг ВМ або імпортуйте том у сховище з правильним ID.
• Якщо сховище недоступне: спочатку відновіть сховище; не редагуйте конфіг ВМ, щоб «обійти» відсутнє сховище, інакше спричините розбіжності конфігурації.
• Якщо том видалено: припиніть експерименти; переорієнтуйтеся на резервні копії, цілі реплікації, снапшоти або відновлення на рівні файлової системи. Кожна додаткова «спроба» — це шанс перезаписати докази.

Порада щодо швидкості: не перезавантажуйте вузол і не «перезапускайте VM», поки не зрозумієте, чи маєте справу з застарілим монтуванням, відсутнім пулом чи реально видаленим томом. Рестарти можуть приховати тимчасові докази в логах і активувати автоматичні ремонти, що змінюють ситуацію.

Цікаві факти та контекст (чому це трапляється знову і знову)

• /etc/pve — це кластерний файловий простір: Proxmox зберігає конфіг у pmxcfs — розподіленому файловому просторі, схожому на базу. Якщо зв’язок кластера порушений, читання конфігу може бути дивно консистентним, але неправильним на різних вузлах.
• ID сховищ — це імена, а не магія: «local-lvm» — це просто мітка в storage.cfg. Перейменування або відтворення сховища з іншим бекендом може тихо зробити посилання на диски недійсними.
• ZFS zvol — це блочний пристрій: у Proxmox диск на zvol не є файлом. «Пошук у директорії» його не знайде; потрібно запитувати ZFS.
• LVM-thin може «брехати» під навантаженням: thinpool може перейти в режим «тільки для читання» або відмовлятися активувати томи при заповненні метаданих. Це може виглядати як «відсутній LV», але насправді «LV не активується».
• Точки монтування можуть «відкритися»: якщо NFS-монтування падає і сервіс створює локальну директорію, ви можете записати образи VM на локальний диск вузла. Пізніше диск «зникає», коли NFS знову перемонтує каталог і сховає локальні файли.
• Статус Ceph «healthy» — це scoped: кластер може бути глобально здоровим, але ваш клієнт може не мати keyring або потрібних caps для перерахування/читання RBD-образу.
• Ідентифікатори томів Proxmox мають структуру: зазвичай вони виглядають як local-lvm:vm-101-disk-0 або tank:vm-101-disk-0. Якщо в конфіг є сирий шлях, хтось, ймовірно, обійшов абстракцію сховища.
• Дрейф конфігів ВМ поширений при міграціях: особливо коли переходять з файл-сховищ (qcow2) на блочні томи (ZFS/LVM/Ceph) або імпортують з інших платформ.
• Снапшоти не захищають від помилок вказівників: снапшоти захищають дані; вони не захищають людину від прикріплення не того диска до не того VMID.

Що насправді означає «disk vanished» у Proxmox

Не існує одного канонічного рядка помилки. Ви побачите варіації залежно від бекенду:

• Proxmox GUI: «unable to find volume» або «volume does not exist».
• qm start: помилки, що посилаються на ідентифікатор тому (наприклад, storage 'local-lvm' does not exist або no such logical volume).
• qemu-system: не може відкрити блочний пристрій, відмовлено в доступі, відсутній файл.

Перекладіть симптом у питання:

• Якщо помилка згадує storage ID (наприклад, local-lvm, tank, ceph-ssd): ймовірно, проблема в storage.cfg або в активації сховища.
• Якщо згадано ім’я тому (vm-101-disk-0): ймовірно, відсутній бекенд-об’єкт, неправильний пул, неправильний VG або диск було переміщено/перейменовано.
• Якщо згадано шлях (наприклад, /mnt/pve/nfs/images/101/vm-101-disk-0.qcow2): ймовірно, проблема з монтуванням/правами/шляхом.

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

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

Все нижче написано для shell хоста Proxmox. Виконуйте від root (або з відповідними привілеями). Кожне завдання включає: команду, чому типовий вивід означає і яке рішення прийняти.

Завдання 1: Визначити точні посилання на диски в конфігурації ВМ

cr0x@server:~$ vmid=101; sed -n '1,200p' /etc/pve/qemu-server/${vmid}.conf
boot: order=scsi0;net0
cores: 4
memory: 8192
name: app-prod-01
scsi0: local-lvm:vm-101-disk-0,discard=on,iothread=1,size=80G
scsi1: tank:vm-101-disk-1,size=200G
net0: virtio=AA:BB:CC:DD:EE:FF,bridge=vmbr0
onboot: 1
ostype: l26
scsihw: virtio-scsi-pci

Значення: тепер у вас є два різні бекенди: local-lvm і tank. Не припускайте, що обидва зламані; діагностуйте по кожному диску окремо.

Рішення: скопіюйте ідентифікатори томів кудись. Наступні кроки — перевірити кожен storage ID і кожен об’єкт тому.

Завдання 2: Перевірити статус сховища Proxmox (active, enabled, content types)

cr0x@server:~$ pvesm status
Name             Type     Status           Total            Used       Available        %
local            dir      active      98420640        21053440        72278144   21.39%
local-lvm        lvmthin  active      402653184       187904000       214749184   46.67%
tank             zfspool  active      1099511627776   603979776000   495531851776   54.93%

Значення: сховища «active». Якщо ВМ все ще не стартує, ймовірно, маємо справу з відсутністю томів, правами або проблемами активації, а не з відключеним визначенням сховища.

Рішення: якщо сховище показано як inactive або відсутнє, виправляйте це перед тим, як чіпати конфіг ВМ.

Завдання 3: Перевірити, що налаштування сховища існує і не зсунулося

cr0x@server:~$ grep -nE '^(dir|lvmthin|zfspool|rbd|lvm|nfs|iscsi):|^content|^path|^pool|^vgname|^monhost|^nodes' /etc/pve/storage.cfg
dir: local
        path /var/lib/vz
        content iso,vztmpl,backup
lvmthin: local-lvm
        thinpool data
        vgname pve
        content images,rootdir
zfspool: tank
        pool tank
        content images,rootdir

Значення: storage IDs відповідають тим, на які посилається конфіг ВМ. Якщо ВМ посилається на storage ID, якого тут немає, Proxmox вважатиме том неіснуючим.

Рішення: якщо storage ID неправильний у конфігу ВМ, виправляйте конфіг уважно, а не намагайтеся «створити сховище з тим ім’ям», яке вказує в інше місце.

Завдання 4: Попросити Proxmox перерахувати згаданий том (агностично до бекенду)

cr0x@server:~$ pvesm list local-lvm --vmid 101
Volid                          Format  Type              Size VMID
local-lvm:vm-101-disk-0         raw     images     85899345920 101

Значення: Proxmox бачить об’єкт диска через плагін сховища. Це сильно свідчить про те, що диск існує і доступний для виявлення.

Рішення: якщо диск перераховано, але ВМ не стартує, шукайте проблеми з правами/блокуванням, застаріліма відображеннями пристроїв або помилки QEMU, а не «відсутній диск».

Завдання 5: Спробуйте перелічити том, який Proxmox вважає відсутнім

cr0x@server:~$ pvesm path tank:vm-101-disk-1
pvesm: volume 'tank:vm-101-disk-1' does not exist

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

Рішення: переключіться на перевірки бекенду (перелік ZFS). Ще не редагуйте конфіг ВМ; том може існувати під трохи іншим ім’ям або в іншому пулі.

Завдання 6: ZFS бекенд: підтвердити, що пул імпортовано і він здоровий

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

Значення: стан пулу не є негайною перешкодою.

Рішення: продовжуйте: перераховуйте datasets/zvol; шукаємо невідповідність імен або переміщення томів.

Завдання 7: ZFS бекенд: пошук відсутнього zvol

cr0x@server:~$ zfs list -t volume -o name,volsize,used,refer,origin | grep -E 'vm-101|101-disk|disk-1' || true
tank/vm-101-disk-0   80G   12G  12G  -
tank/vm-102-disk-1  200G   68G  68G  -

Значення: очікуваного tank/vm-101-disk-1 тут немає. Але ви бачите підозріле: tank/vm-102-disk-1 існує і має саме той розмір, який ви очікували для другого диска VM 101.

Рішення: з’ясуйте, чи прикріплені диски до неправильного VMID або чи перейменували їх. Саме тут «конфіг проти сховища» стає судовою справою.

Завдання 8: Перевірити, який конфіг ВМ посилається на підозрілий том

cr0x@server:~$ grep -R --line-number "tank:vm-102-disk-1" /etc/pve/qemu-server/*.conf
/etc/pve/qemu-server/102.conf:6:scsi1: tank:vm-102-disk-1,size=200G

Значення: ВМ 102 посилається на нього, отже, ймовірно, том справді прикріплено туди. Але «ймовірно» — це не план.

Рішення: якщо диск VM 101 відсутній, а VM 102 має зайвий диск, підтвердіть це через ідентифікатори на рівні гостя (UUID файлової системи, дані застосунку) перед тим, як щось перепідключати.

Завдання 9: LVM-thin бекенд: підтвердити наявність VG і thinpool

cr0x@server:~$ vgs; lvs -a -o vg_name,lv_name,lv_attr,lv_size,pool_lv,data_percent,metadata_percent
  VG  #PV #LV #SN Attr   VSize   VFree
  pve   1  12   0 wz--n- 372.51g  1.00g
  VG   LV                Attr       LSize   Pool      Data%  Meta%
  pve  data              twi-aotz-- 350.00g           62.15  11.02
  pve  vm-101-disk-0      Vwi-aotz--  80.00g data     15.63

Значення: vm-101-disk-0 існує в LVM-thin і активний. Використання даних/метаданих тут не викликає тривоги. Якщо метадані на 99% і активація LV падає, часто ви побачите симптом «відсутнього пристрою».

Рішення: якщо thinpool не активний або метадані вичерпані, відновіть стан thinpool перед тим, як «створювати» томи заново.

Завдання 10: Директорійне сховище: виявити пастку «порожньої точки монтування»

cr0x@server:~$ mount | grep -E '/mnt/pve|nfs|cifs' || true
server-nfs:/export/pve-images on /mnt/pve/nfs-images type nfs4 (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2)

cr0x@server:~$ ls -lah /mnt/pve/nfs-images/images/101/ | head
total 80G
drwxr-xr-x 2 root root 4.0K Dec 26 01:50 .
drwxr-xr-x 3 root root 4.0K Dec 26 01:50 ..
-rw-r----- 1 root root 80G Dec 26 01:49 vm-101-disk-0.qcow2

Значення: монтування існує і очікувана директорія містить диск. Якщо вивід mount порожній, але директорія ще є — ви можете дивитися на локальні файли, а не на NFS-шару.

Рішення: якщо монтування відсутнє, зупиніть ВМ негайно, якщо вона пише в неправильне місце. Перемонтуйте, потім звірте, яка копія є авторитетною.

Завдання 11: Перевірити блокування, які роблять диск «недоступним»

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

cr0x@server:~$ qm config 101 | grep -E '^lock:|^scsi|^virtio|^sata|^ide'
scsi0: local-lvm:vm-101-disk-0,discard=on,iothread=1,size=80G
scsi1: tank:vm-101-disk-1,size=200G

Значення: рядок lock не показано. Якщо ви бачите lock: backup або lock: migrate, Proxmox може блокувати операції, і користувачі сприймають це як «відсутній диск». Це не відсутність; це захист.

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

Завдання 12: Запустіть ВМ, щоб отримати реальне повідомлення про помилку (не покладайтеся на GUI)

cr0x@server:~$ qm start 101
kvm: -drive file=/dev/zvol/tank/vm-101-disk-1,if=none,id=drive-scsi1,format=raw,cache=none,aio=io_uring: Could not open '/dev/zvol/tank/vm-101-disk-1': No such file or directory
start failed: QEMU exited with code 1

Значення: QEMU намагається відкрити шлях до zvol і його немає. Це підтверджує, що це не «проблема GUI Proxmox». Бекенд-об’єкт відсутній або перейменований.

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

Завдання 13: Пошук логів за подіями видалення/перейменування і помилок сховища

cr0x@server:~$ journalctl -u pvedaemon -u pvestatd -u pvesm -u pveproxy --since "24 hours ago" | tail -n 40
Dec 26 01:41:12 server pvedaemon[2210]: update VM 101: moved disk scsi1 to tank
Dec 26 01:41:15 server pvedaemon[2210]:  end task UPID:server:000008A2:0000F1A3:676C3B6B:qmmove:101:root@pam: OK
Dec 26 02:10:33 server pvedaemon[2210]:  start task UPID:server:00000B11:00012A3D:676C4BE9:qmstart:101:root@pam:
Dec 26 02:10:34 server pvedaemon[2210]: command 'qmstart 101' failed: exit code 1

Значення: у вас є підказка: хтось перемістив диск нещодавно. «Move disk to tank» пройшов успішно, але згодом zvol відсутній. Це натякає на подальше видалення, відкат або зміну пулу.

Рішення: зіставте це з історією ZFS, подіями відкату або діями операторів у проміжку 01:41–02:10.

Завдання 14: Історія ZFS (якщо включена) для фіксації destroy/rename

cr0x@server:~$ zpool history tank | tail -n 20
2025-12-26.01:41:13 zfs create -V 214748364800 tank/vm-101-disk-1
2025-12-26.01:41:14 zfs set volblocksize=16K tank/vm-101-disk-1
2025-12-26.01:58:02 zfs destroy tank/vm-101-disk-1

Значення: том створено, потім знищено. Це вже не «таємниче зникнення». Це «видалено», що зовсім інший випадок.

Рішення: припиніть спроби запуску ВМ; переходьте до відновлення з резервної копії/снапшоту або опцій відновлення ZFS (залежно від політики вашого середовища).

Завдання 15: Ceph RBD бекенд: перевірити наявність образу та права

cr0x@server:~$ ceph -s
  cluster:
    id:     7d2a2f1c-1a11-4f2b-bc1a-0c3f0c0d0d0d
    health: HEALTH_OK
  services:
    mon: 3 daemons, quorum mon1,mon2,mon3
    osd: 6 osds: 6 up, 6 in
  data:
    pools:   2 pools, 128 pgs
    objects: 1.2M objects, 4.6 TiB
    usage:   13 TiB used, 20 TiB / 33 TiB avail

cr0x@server:~$ rbd -p rbd ls | grep -E 'vm-101-disk-0|vm-101-disk-1' || true
vm-101-disk-0

Значення: кластер здоровий, але існує лише один образ. Якщо Proxmox очікує другий — він не стартуватиме. Це також може статися, якщо ви використовуєте невірну назву пулу або не враховуєте namespace в RBD.

Рішення: перевірте storage.cfg на правильність pool/namespace; переконайтесь, який вузол має потрібний keyring та caps.

Завдання 16: Підтвердити, що Proxmox розв’язує шлях до диска (перевірка sanity плагіна сховища)

cr0x@server:~$ pvesm path local-lvm:vm-101-disk-0
/dev/pve/vm-101-disk-0

Значення: Proxmox може розв’язати volid у реальний шлях блочного пристрою. Якщо QEMU все ще падає, причина, ймовірно, в правах, застарілих пристроях або відображеннях ядра.

Рішення: перевірте, чи існує вузол пристрою і чи доступний він, а також чи коректна активація LVM.

Завдання 17: Переконатися, що блочний вузол існує і має правильні права

cr0x@server:~$ ls -lah /dev/pve/vm-101-disk-0
lrwxrwxrwx 1 root root 7 Dec 26 00:02 /dev/pve/vm-101-disk-0 -> ../dm-12

cr0x@server:~$ ls -lah /dev/dm-12
brw-rw---- 1 root disk 253, 12 Dec 26 00:02 /dev/dm-12

Значення: пристрій існує. Якби його не було — ви б побачили «No such file» і зосередилися б на активації LVM та udev-правилах.

Рішення: якщо вузли пристроїв відсутні, виконайте кроки з активації LVM і дослідіть, чому вони не з’явилися (VG не знайдено, multipath, iSCSI-сесія впала).

Завдання 18: Знайти застарілі відображення для шляхів ZFS zvol

cr0x@server:~$ ls -lah /dev/zvol/tank/ | head
total 0
drwxr-xr-x 2 root root  80 Dec 26 01:41 .
drwxr-xr-x 4 root root  80 Dec 26 01:41 ..
lrwxrwxrwx 1 root root  13 Dec 26 01:41 vm-101-disk-0 -> ../../../zd0

Значення: відсутній zvol дійсно не присутній; інакше ви б бачили симлінк для нього. Це узгоджується з помилкою QEMU з Завдання 12.

Рішення: не чіпайте конфіг ВМ. Ваше виправлення: відновити zvol (зі снапшоту/резервної копії) або перепідключити правильний існуючий zvol, якщо його перейменували.

Три корпоративні міні-історії із практики

Міні-історія 1: Інцидент через хибне припущення

Середня SaaS-компанія мала Proxmox-кластер, де «local-lvm» існував на кожному вузлі, але не ідентично. На папері це виглядало як «той самий VG ім’я на кожному вузлі», що звучить правдоподібно, поки не почнеш питати, що саме це означає.

ВМ була змінена з вузла A на вузол B після апаратної тривоги. Proxmox оновив конфіг ВМ, і VM успішно запустилась. Через тиждень диск «зник» після ребута. Паніка. Команда зберігання звинуватила Proxmox. Адмін Proxmox — зберігання. Класичний дует.

Хибне припущення: «Якщо storage ID однаковий, контент сховища теж однаковий». На вузлі B «local-lvm» вказував на інший VG через попереднє відновлення. Це працювало тимчасово, бо VM працювала і блочні пристрої залишалися змепленими до перезавантаження. Після ребута активація LV не знайшла очікуваного тому.

Виправлення було не героїчним: уніфікували імена VG та storage ID, і перестали використовувати спільні мітки для несумісного локального сховища. Корінь проблеми — колізія імен. Урок: storage ID Proxmox — це не обіцянка спільної семантики. Це рядок у файлі.

Міні-історія 2: Оптимізація, яка обернулася проти

Велика внутрішня команда хотіла швидших клонів і менше снапшотів на дорогому флеші. Вони впровадили заплановану задачу, яка агресивно чистила «старі» ZFS-томи за шаблоном для тимчасових тестових ВМ. Було акуратно. Було чисто. І було невірно.

Виробнича ВМ нещодавно переміщалася з LVM-thin на ZFS. Під час міграції людина перейменувала диск, щоб він відповідав внутрішнім конвенціям — на жаль, ці конвенції перетиналися з патерном «тимчасових» томів. VM працювала два дні, доки завдання не виконало те, що йому наказали, і не знищило zvol.

Інцидент виглядав як «VM disk vanished». Proxmox не брехав; диск був видалений. Команда спочатку хотіла створити порожній zvol з тим самим ім’ям, щоб VM запустилася. Це був би швидкий спосіб знищити всі шанси на відновлення. Хтось їх зупинив.

Вони відновили дані з бекапу, потім змінили політику: завдання видалення тепер перевіряє посилання в /etc/pve/qemu-server перед знищенням чого-небудь. Також імена дисків перестали бути вільним текстом. «Оптимізація» — це ще один спосіб ввести новий режим відмови, якщо не додати захисні огорожі.

Міні-історія 3: Нудна, але правильна практика, яка врятувала день

Фінансова організація використовувала Proxmox з Ceph RBD для дисків ВМ і мала суворе правило: кожен тикет зі зміною сховища включав «крок доказу» — вивід pvesm status, qm config і бекенд-переліку (rbd ls або zfs list) до і після.

Це було бюрократично. Люди зітхали. Але це також означало, що завжди був невеликий слід об’єктивної правди. Одного дня вузол ребутнувся після оновлення ядра, і кілька ВМ відмовилися стартувати з повідомленням «unable to find volume». Через зміну вони порівняли виводи до/після. Конфіги ВМ посилалися на ceph-ssd, але storage.cfg тепер містив ceph_ssd через перейменування за стандартом.

Диски нікуди не переміщувалися. Ceph був у порядку. Лише мітка storage ID змінилася, порушивши всі посилання. Вони відкотили ім’я storage ID, перезавантажили, і все піднялося.

Нічого витонченого. Ніякого відновлення даних. Ніяких вгадувань. Просто дисциплінований слід змін, який зробив відмову очевидною. Нудні практики не отримують нагород, але вони забезпечують доступність.

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

1) «Volume does not exist» одразу після перейменування сховища

Симптом: конфіги ВМ посилаються на old-storage:vm-XXX-disk-Y; pvesm status не показує old-storage.

Корінь: змінено storage ID у /etc/pve/storage.cfg, але конфіги ВМ не оновлено.

Виправлення: відкотіть ім’я storage ID або оновіть конфіги ВМ на новий storage ID (тільки якщо бекенд справді той самий). Потім перевірте pvesm list і qm start.

2) Відсутні QCOW2 файли після NFS-перебою

Симптом: файли «зникли» з /mnt/pve/nfs-*; директорія існує, але порожня; пізніше знову з’являється.

Корінь: монтування впало; хост писав у локальну директорію; після перемонтування локальні файли сховалися.

Виправлення: перемонтуйте правильно, потім звірте дублікатні копії. Підтвердіть за mount і порівняйте inode/device ID. Запобігайте через systemd mount units з жорсткими залежностями і моніторингом помилок типу stale file handle.

3) ZFS пул імпортовано на одному вузлі, але не на іншому (плутанина в кластері)

Симптом: ВМ стартує на Вузлі A, але не на Вузлі B; Вузол B каже, що шлях zvol відсутній.

Корінь: локальний ZFS пул не імпортовано на Вузлі B; Proxmox вважав його спільним, але це не так.

Виправлення: імпортуйте пул на правильному вузлі або припиніть вважати його спільним сховищем. Використовуйте правильний тип сховища і обмеження вузлів у storage.cfg.

4) LVM-thin «відсутній LV» під час вичерпання метаданих thinpool

Симптом: LV ніби відсутній, ВМ не стартує; метадані thinpool близькі до 100%.

Корінь: thinpool не може виділити метадані; активація LV провалюється; вузли пристроїв можуть не з’явитися.

Виправлення: розширте метадані LV, зменшіть кількість снапшотів, виконайте ремонт thinpool за потреби. Потім реактивуйте VG і повторіть спробу.

5) «Permission denied» виглядає як відсутній диск

Симптом: QEMU не може відкрити файл/блочний пристрій; GUI повідомляє, що диск недоступний.

Корінь: неправильні права/власник для директорійного сховища, AppArmor/SELinux політика або зламані ACL на NFS.

Виправлення: виправте права, переконайтесь, що Proxmox налаштовано для цього типу сховища, і повторіть тест з pvesm path та прямим ls -l.

6) Диск існує, але під іншим іменем (людське перейменування)

Симптом: конфіг ВМ посилається на vm-101-disk-1, але бекенд має vm-101-data або інше ім’я диска.

Корінь: ручне перейменування на бекенді або під час міграції/відновлення.

Виправлення: підтверджуйте правильний том за розміром, часом створення, лінією снапшотів і ідентифікаторами файлової системи гостя; потім оновіть конфіг ВМ на реальний volid.

7) Резервні копії відновлено на неправильний storage ID

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

Корінь: ціль відновлення відрізняється від оригіналу; конфіг не переписано як очікувалося.

Виправлення: відновлюйте з явним відображенням сховища, потім підтвердіть через qm config і pvesm list.

8) Ceph виглядає в порядку, але RBD-образ «відсутній» для Proxmox

Симптом: ceph -s OK; Proxmox не може перелічити образи або відкрити один.

Корінь: неправильний pool/namespace у storage.cfg, відсутній keyring на цьому вузлі або недостатні caps.

Виправлення: перевірте storage.cfg, переконайтесь, що keyring є на вузлі, протестуйте rbd -p POOL ls як root і в тому ж оточенні, яке використовує Proxmox.

Ще один короткий жарт: Сховище як плітки — коли з’являється неправильне ім’я (неправильний storage ID), усі його повторюють, поки ви не виправите джерело.

Чеклісти / покроковий план

Покроково: коли ВМ не стартує через відсутній диск

1. Заморозьте сцену. Якщо ВМ зупинена, залиште її зупиненою, поки не з’ясуєте, чи маєте справу з видаленням чи відображенням. Якщо вона працює, але повідомляє про відсутній диск при ребуті — не перезавантажуйте вдруге.
2. Витягніть посилання на диски. Прочитайте /etc/pve/qemu-server/<vmid>.conf. Запишіть кожен рядок диска і volid.
3. Перевірте, чи існують і активні storage IDs. pvesm status. Якщо неактивні — виправте спочатку сховище (монтування, імпорт пулу, мережа).
4. Перелік на рівні Proxmox. pvesm list <storage> --vmid <vmid>. Якщо том перераховано — «відсутній диск» імовірно не відсутній.
5. Перелік на рівні бекенду. ZFS: zfs list -t volume. LVM: lvs. Директорій: find файл. Ceph: rbd ls.
6. Якщо невідповідність: шукайте схожі matches. Grep конфіги ВМ на схожі імена томів; перевірте прикріплення до неправильного VMID.
7. Перевірте логи. journalctl на предмет завдань move/delete; історію ZFS або логи Ceph по можливості.
8. Обирайте режим відновлення.
   • Вказівник неправильний: оновіть конфіг ВМ або імпортуйте том заново.
   • Сховище недоступне: відновіть доступ до сховища.
   • Том видалено: відновлюйте з бекапу/снапшоту; розгляньте відновлення ZFS, якщо політика дозволяє.
9. Підтвердіть перед завантаженням. Переконайтеся, що pvesm path <volid> працює для кожного диска в конфігу.
10. Запустіть один раз, спостерігайте вивід. qm start з CLI; зафіксуйте повну помилку, якщо не вдалося.
11. Післяінцидентне прибирання. Документуйте, який шар вийшов з ладу (конфіг чи сховище) і додайте монітор/огорожу.

Чекліст: чого не робити під тиском

• Не створюйте новий порожній диск з тим самим ім’ям «щоб він запустився». Це спосіб стерти докази і гарантувати втрату даних.
• Не перейменовуйте storage IDs необережно. Якщо потрібно — плануйте масове оновлення конфігів і робіть dry-run.
• Не вважайте, що «active» означає «правильний». NFS може бути активним, але вказувати на неправильний експорт.
• Не трактуйте локальне сховище як спільне. Якщо пул/VG існує лише на одному вузлі — обмежте його використання.
• Не знімайте блокування бездумно. Блокування часто є єдиним запобіжником від погіршення ситуації.

Чекліст: запобігання, яке справді працює

• Уніфікуйте storage IDs і контролюйте їх через рев’ю. Імена — це залежність.
• Моніторьте наявність монтувань і «коректність монтування» (ідентифікатор пристрою, а не лише існування директорії).
• Сповіщення про невдачі імпорту ZFS пулів і використання метаданих LVM thinpool.
• Запускайте нічний аудит: для кожного volid диска ВМ перевіряйте, чи існує він на бекенді і чи розв’язується через pvesm path.
• Вимагайте доказів змін (виводи до/після) для операцій зі сховищем: move, rename, delete, зміни пулу.

FAQ

1) Як визначити, чи це проблема конфігурації чи сховища?

Якщо pvesm list не бачить том і бекенд-перелік теж не бачить — це реальність сховища/об’єкта. Якщо бекенд його показує, але Proxmox не може розв’язати — це невідповідність конфігурації/визначення сховища.

2) Конфіг ВМ посилається на local-lvm, але pvesm status показує його неактивним. Що швидше?

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

3) Чи можна просто редагувати /etc/pve/qemu-server/<vmid>.conf вручну?

Так, але робіть це свідомо: зробіть копію, змініть одну річ, і перевірте за допомогою qm config і pvesm path. Пам’ятайте, що /etc/pve керується кластером.

4) Я бачу zvol як tank/vm-101-disk-1, але Proxmox каже, що його немає.

Зазвичай це невідповідність storage.cfg (неправильна назва пулу), обмеження по вузлам або том у іншому dataset/pool, ніж того очікує Proxmox. Переконайтесь, що визначення сховища вказує на той самий пул і що вузол має доступ.

5) Файл диска існує на NFS, але Proxmox не може його відкрити.

Перевірте опції монтування і права/власника. Також впевніться, що ви не дивитесь на локальну директорію через те, що монтування впало. Вивід mount — суддя.

6) Що означає, якщо ВМ стартує на одному вузлі, але не після міграції?

Зазвичай це означає, що сховище не є справді спільним або не ідентично визначено на кожному вузлі. Proxmox може перемістити конфіг, але не може створити локальний VG на іншому вузлі.

7) Який найнадійніший спосіб відновлення, якщо том видалено?

Зупиніться, підтвердіть видалення (журнали бекенду/історія), потім відновіть з бекапу або снапшоту. Якщо є ZFS snapshots/реплікація — відновіть dataset/zvol і потім перепідключіть за volid.

8) Чому Proxmox іноді показує диск у GUI, але запуск все одно не вдається?

Тому що перерахувати метадані легше, ніж відкрити пристрій. Ви можете «бачити» volid, але QEMU все ще може впасти через права, застарілі вузли пристроїв, проблеми активації або бекенд в режимі read-only.

9) Як запобігти тому, щоб перейменування сховища не ламало ВМ?

Не перейменовуйте storage IDs на місці, якщо не плануєте координоване оновлення конфігів. Якщо потрібно — оновіть конфіги ВМ у контрольоване вікно змін і перевірте pvesm path для кожного диска.

10) Чи існує одна команда, яка знаходить биті посилання на диски?

Не одна досконала, але ви можете написати скрипт: ітеруйте VMID, парсіть рядки дисків, запускайте pvesm path і відмічайте помилки. Саме відсутність такого аудиту й дозволяє цим інцидентам повторюватися.

Висновок: наступні кроки, щоб не повторилося

Діагностика «VM disk vanished» — це в основному дисципліна не плутати шари. Конфіг Proxmox — це набір вказівників. Сховище — набір об’єктів. Ваше завдання — знайти невідповідність з доказами, а не на основі відчуттів.

Наступні кроки, які варто виконати насправді:

• Впровадьте щоденний аудит: для кожного volid диска ВМ перевіряйте, що pvesm path розв’язується і бекенд-об’єкт існує.
• Укріпіть монтування та імпорт пулів: ставте «коректність монтування» і «імпорт пулу» як моніторинговані SLO, а не як припущення.
• Контроль змін для storage IDs: edits у storage.cfg мають проходити рев’ю як код. Імена — це залежності.
• Запишіть ваші правила відновлення: «ніколи не створювати відсутнє ім’я диска заново», «перевіряти наявність бекенду перед редагуванням конфігу», і «спочатку логи, потім ребут».

Найкращий результат — це не хитромудре відновлення. Це нудний інцидент, який більше не трапляється, тому що ви зробили механізм втрати дисків складнішим для помилки.