Знімок Proxmox завис: безпечне очищення залишків LVM-thin

December 17, 2025 • February 3, 2026 • Читання: 6 хв • Views: 7

Було корисно?

Ви натискаєте «Delete snapshot» у Proxmox. Завдання крутиться. Потім воно провалюється. Або ще гірше: воно каже, що успішно завершено, але сховище все ще показує примарні томи, ваш thin pool усе ще роздутий, а резервні копії продовжують наступати на ту саму міну.

Це — сувора реальність LVM-thin у навантаженому віртуалізаційному кластері: створення знімків дешеве, поки не стає дорогим, а очищення безпечне тільки якщо ви розумієте, що реально виділено, що лише посилається, а що явно сирітське.

Ментальна модель: як Proxmox + LVM-thin насправді працюють зі знімками

Якщо ви сприймаєте «знімок» як магічну машину часу, рано чи пізно видалите не те. Сприймайте його як елемент зберігання з лічильниками посилань і поведінкою copy-on-write — і спатимете спокійніше.

Що робить Proxmox, коли ви натискаєте «Snapshot»

Для сховища LVM-thin (lvmthin у Proxmox) диск ВМ зазвичай є thin-томом всередині thin pool. Знімок — це інший thin-том, який ділиться блоками з базовим томом. Записи йдуть в інше місце; читання може надходити зі спільних блоків або з дельта-блоків. Те «інше місце» все ще ваш thin pool. Thin provisioning — це не вільне місце; це відкладений облік.

Proxmox відстежує знімки у конфігурації ВМ (/etc/pve/qemu-server/<vmid>.conf) і використовує LVM-інструменти під капотом. Коли видалення знімка не вдається, часто виникає розбіжність між:

інвентарем Proxmox (що він вважає існуючим)
реальністю LVM (які thin-томи існують і хто на кого посилається)
станом device-mapper (що активне, відкрите або призупинене)

Як виглядають «залишки» в LVM-thin

Залишки проявляються як thin-томи, для яких більше немає відповідного посилання в конфігурації ВМ, або як томи-знімки, у яких видалено джерело, або як томи, які Proxmox хотів би видалити, але LVM відмовляється, бо щось ще тримає їх відкритими.

Типові схеми залишків:

Сирітський thin LV-знімок: запис про знімок у ВМ зник, але thin LV залишився.
Сирітський базовий диск: диск ВМ був переміщений або видалений на рівні Proxmox, але thin LV досі існує.
«зайняті» пристрої: qemu, qemu-nbd, інструменти для резервного копіювання або навіть застарілі відображення device-mapper тримають LV відкритим.
тиск на метадані thin pool: видалення та злиття стають повільними або зазнають невдач, коли метадані майже повні або пул нездоровий.

Одна цитата, бо це й досі правда

Парафразована думка (Werner Vogels): готуйтесь до відмови як до нормального робочого стану, а не як до рідкісного винятку.

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

Не блукайте. Не «просто перезавантажуйте вузол», якщо ви не можете допустити простою і точно знаєте, які пристрої відкриті. Зробіть натомість це.

1) Перевірте, чи Proxmox завис через свої локи або працююче завдання

Чи є запущене завдання на видалення/відкат знімка?
Чи є застарілий лок у конфігурації ВМ?
Чи не конкуруєте ви з резервним копіюванням (vzdump) або роботою реплікації?

2) Перевірте стан thin pool і використання метаданих

Чи дані або метадані thin pool наближаються до 100%?
Чи є попередження про ID транзакцій, needs-check або режим лише для читання?
Чи реагує dmeventd/lvmmonitor, або його вимкнуто?

3) Визначте, хто тримає LV відкритим

Чи qemu все ще працює?
Чи пристрій mapper все ще активний?
Чи щось на кшталт qemu-nbd або застарілий монтування тримає його?

Як тільки ви знаєте, яка з трьох причин є вузьким місцем, очищення стає переважно механічним. Якщо не знаєте — кожна команда це підкидання монети.

Цікаві факти та контекст (бо історія повторюється)

Знімки LVM передували тонкому провізіонуванню. Класичні LVM-знімки були відомі високим споживанням простору і повільністю при інтенсивних записах; thin-знімки змінили профіль продуктивності, але не операційні гострі кути.
Device-mapper — це справжній двигун. LVM — це оркестрація в простірі користувача; мапінг, відстеження посилань і поведінку thin забезпечує ядро Linux через device-mapper.
Метадані thin pool — це окремий «диск». Коли метадані заповнюються, пул може перейти в режим тільки для читання, щоб уникнути корупції. Видалення можуть стати неможливими в найгірший момент — саме тоді, коли вам потрібен простір.
Видалення знімків може бути дорогою операцією. Видалення thin-знімка може спричинити звільнення блоків і оновлення метаданих, що не є «безкоштовним», особливо на завантажених пулах.
Proxmox використовує стан конфігурації як істину. Якщо конфіг і зберігання розходяться, UI може брехати з прямим виразом. Система не зла; вона просто читає іншу книжку, ніж LVM.
Thin provisioning може приховувати ризики. Перепризначення працює, поки не перестає; режим відмови — різкий і неприємний, і зазвичай трапляється під час інтенсивних операцій зі знімками.
Старіші ядра мали гірші історії ремонту thin. Інструменти для метаданих thin покращились з часом, але ремонт досі — це тип «успіху», що приносить головний біль і постмортем.
Шторми знімків існують насправді. Повторні цикли створення/видалення знімків можуть фрагментувати метадані і підсилити затримки так, що це дивує людей, які дивляться лише на сирі графіки IOPS.

Жарт #1: Знімок як абонемент у спортзал — дешевий у створенні, загадково дорогий, коли хочеш від нього позбутися.

Практичні завдання з командами: діагноз, рішення, дії

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

Завдання 1: Підтвердити тип сховища і назву, які використовує Proxmox

cr0x@server:~$ pvesm status
Name             Type     Status           Total            Used       Available        %
local             dir     active        197919072        45121480       142663256   22.80%
local-lvm      lvmthin    active        9996536384      7125647360      2870889024   71.28%

Що це означає: У вас є сховище lvmthin з назвою local-lvm. Залишки знімків будуть thin LV всередині VG, який підтримує це сховище (зазвичай pve).

Рішення: Користуйтесь інструментами LVM-thin, а не ZFS-утилітами і не «видаляти випадкові файли». Ваш шлях очищення — це lvs/lvremove/dmsetup, плюс гігієна конфігурацій Proxmox.

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

cr0x@server:~$ qm listsnapshot 104
`-> current
   `-> pre-upgrade-2025w51  2025-12-18 02:14:09  VM snapshot
   `-> before-agent-change  2025-12-20 11:07:55  VM snapshot

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

Рішення: Якщо Proxmox перераховує знімки, віддавайте перевагу видаленню через qm delsnapshot. Ручні видалення LVM потрібні, коли стан вже неконсистентний або Proxmox завис.

Завдання 3: Шукати локи в конфігурації ВМ, що блокують операції зі знімками

cr0x@server:~$ grep -E '^(lock:|snapshots:)' /etc/pve/qemu-server/104.conf
lock: snapshot

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

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

Завдання 4: Перевірити історію завдань Proxmox для невдалих операцій

cr0x@server:~$ journalctl -u pvedaemon -u pveproxy --since "2 hours ago" | tail -n 30
Dec 26 09:10:14 server pvedaemon[2214]: starting task UPID:server:0000B5AA:0001B2C1:676D6E46:qmddelsnapshot:104:root@pam:
Dec 26 09:10:16 server pvedaemon[2214]: command 'lvremove -f pve/vm-104-disk-0-pre--upgrade--2025w51' failed: exit code 5
Dec 26 09:10:16 server pvedaemon[2214]: error: Logical volume pve/vm-104-disk-0-pre--upgrade--2025w51 contains a filesystem in use.
Dec 26 09:10:16 server pvedaemon[2214]: TASK ERROR: command 'lvremove -f pve/vm-104-disk-0-pre--upgrade--2025w51' failed: exit code 5

Що це означає: Це не «дивність UI Proxmox». LVM відмовив, бо пристрій «використовується». Зазвичай це відкритий дескриптор файлу, застарілий mapper-пристрій або qemu, що все ще посилається на нього.

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

Завдання 5: Знайти LVM thin-томи для ВМ і зіставити імена знімків з LV

cr0x@server:~$ lvs -a -o vg_name,lv_name,lv_attr,origin,devices,lv_size,data_percent,metadata_percent pve | grep -E 'vm-104'
pve  vm-104-disk-0                             Vwi-aotz--                                    thinpool           200.00g  78.12
pve  vm-104-disk-0-pre--upgrade--2025w51       Vwi---tz-k  vm-104-disk-0                     thinpool           200.00g  12.44
pve  vm-104-disk-0-before--agent--change       Vwi---tz-k  vm-104-disk-0                     thinpool           200.00g   3.02

Що це означає: У вас є базовий диск і два thin-знімки. origin вказує назад на базовий. Атрибути (Vwi---) означають, що це thin-томи й вони активні.

Рішення: Якщо LV існують, Proxmox не привиджується. Якщо Proxmox вважає, що знімок існує, але тут його немає — маєте справу з дрейфом стану і треба виправляти конфігурацію.

Завдання 6: Переглянути стан thin pool (дані + використання метаданих)

cr0x@server:~$ lvs -o vg_name,lv_name,lv_attr,lv_size,data_percent,metadata_percent pve
VG   LV        Attr       LSize   Data%  Meta%
pve  root      -wi-ao----  96.00g
pve  swap      -wi-ao----   8.00g
pve  thinpool  twi-aotz--   7.30t  71.28  92.10

Що це означає: Метадані на 92% — це жовтий маячок. Виснаження метаданих thin pool спричиняє дивні помилки: видалення зависають, пул переходить у read-only, виділення не вдаються, і ви вивчаєте нові матючні слова.

Рішення: Якщо метадані >80% — надайте пріоритет очищенню або розширенню метаданих перед агресивним створенням/видаленням знімків. Якщо >95% — поводьтесь, як при інциденті.

Завдання 7: Перевірити, чи ВМ запущена і може досі посилатися на пристрої знімків

cr0x@server:~$ qm status 104
status: running

Що це означає: Запущена ВМ може тримати пристрої відкритими. Видалення знімка зазвичай націлене на LV-знімок, але залежно від операцій (відкат, резервне копіювання, клонування) можуть існувати додаткові відображення.

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

Завдання 8: Знайти, хто тримає LV відкритим (lsof/fuser на шляху пристрою)

cr0x@server:~$ lsof /dev/pve/vm-104-disk-0-pre--upgrade--2025w51 | head
COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
qemu-syst 915 root   49u  BLK  253,7      0t0  891 /dev/dm-7

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

Рішення: З’ясуйте, чому qemu тримає snapshot LV. Зазвичай: блокова операція, резервне копіювання або спроба відкату. Не вбивайте qemu навмання, якщо ви не готові до впливу на ВМ.

Завдання 9: Зіставити вузли device-mapper з людськими іменами

cr0x@server:~$ dmsetup ls --tree | sed -n '1,80p'
pve-thinpool (253:2)
 ├─pve-vm--104--disk--0 (253:3)
 ├─pve-vm--104--disk--0--pre--upgrade--2025w51 (253:7)
 └─pve-vm--104--disk--0--before--agent--change (253:8)

Що це означає: Знімок — це dm-пристрій. Якщо він відкритий, dm не дозволить LVM акуратно його видалити.

Рішення: Використовуйте це зіставлення, щоб підтвердити, що саме відкрите, і уникати мислення «rm -rf». Також можна використати dmsetup info для перевірки лічильника відкриттів.

Завдання 10: Перевірити лічильник відкриттів на проблемному пристрої

cr0x@server:~$ dmsetup info -c /dev/mapper/pve-vm--104--disk--0--pre--upgrade--2025w51
Name  Maj Min Stat Open Targ Event  UUID
pve-vm--104--disk--0--pre--upgrade--2025w51 253 7 L--w 1 1 0 LVM-6l3B0bQyQq0yYV3uQ0sG0fQxY3o2mV3S

Що це означає: Open = 1. Щось має його відкритим. Це пояснює помилку lvremove.

Рішення: Знайдіть і зупиніть тіло, що тримає його (бажано), або закінчіть операцію, що його тримає, а потім повторіть видалення. Якщо Open = 0 і lvremove все одно не вдається — маєте справу з застарілими відображеннями або дивними метаданими LVM.

Завдання 11: Перевірити наявні резервні завдання або резервні копіювання, що використовують знімки

cr0x@server:~$ ps aux | grep -E 'vzdump|qemu-nbd|pbs-client' | grep -v grep
root     18444  2.1  0.1  35472 12896 ?        Ss   09:05   0:16 vzdump 104 --mode snapshot --compress zstd

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

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

Завдання 12: Спробувати видалити підтримуваним способом (після усунення кореня проблеми)

cr0x@server:~$ qm delsnapshot 104 pre-upgrade-2025w51
delete snapshot 'pre-upgrade-2025w51'
TASK OK

Що це означає: Proxmox керував видаленням, оновив стан конфігурації і попросив LVM видалити потрібний LV.

Рішення: Повторно перевірте використання thin pool і що LV фактично зник. «TASK OK» — це необхідна, але не достатня умова.

Завдання 13: Підтвердити, що LV дійсно видалено (довіряй, але перевіряй)

cr0x@server:~$ lvs -a pve | grep -E 'vm-104-disk-0-pre--upgrade'

Що це означає: Відсутній вивід означає, що LV видалено.

Рішення: Якщо він все ще присутній, у вас часткова невдача: стан Proxmox каже «видалено», але LVM ні. Ось тоді починається ручне очищення — робіть його обережно.

Завдання 14: Знайти «невідомі» томи з перспективи Proxmox

cr0x@server:~$ pvesm list local-lvm | grep -E 'vm-104|unused|snap' | head -n 20
local-lvm:vm-104-disk-0        vmimage 200.00g
local-lvm:vm-104-disk-0-before--agent--change  vmimage 200.00g

Що це означає: Proxmox усе ще бачить snapshot LV «before-agent-change» як VM-образ. Це може бути коректно або залишок, залежно від qm listsnapshot.

Рішення: Якщо Proxmox не перераховує знімок, але pvesm list його показує — розглядайте як кандидат на сирітство і підтвердіть посилання перед видаленням.

Завдання 15: Перевірити конфіг ВМ на наявність «unused» дисків, що вказують на старі LV

cr0x@server:~$ grep -E '^(scsi|virtio|sata|unused)[0-9]+:' /etc/pve/qemu-server/104.conf
scsi0: local-lvm:vm-104-disk-0,size=200G
unused0: local-lvm:vm-104-disk-0-before--agent--change

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

Рішення: Якщо він справді не потрібен — видаліть через Proxmox, щоб оновити інвентар, потім перевірте LVM.

Завдання 16: Безпечно видалити непотрібний диск через інструменти Proxmox

cr0x@server:~$ qm unused 104
unused0: local-lvm:vm-104-disk-0-before--agent--change

cr0x@server:~$ qm set 104 --delete unused0
update VM 104: -delete unused0

Що це означає: Посилання в конфігурації видалено. Залежно від сховища і налаштувань, підлягаючий LV може ще існувати, поки ви явно його не видалите.

Рішення: Тепер видаліть том через pvesm free (бажано) або lvremove (тільки якщо ви підтвердили, що це сирота).

Завдання 17: Звільнити том за допомогою менеджера сховища Proxmox

cr0x@server:~$ pvesm free local-lvm:vm-104-disk-0-before--agent--change
successfully removed 'local-lvm:vm-104-disk-0-before--agent--change'

Що це означає: Proxmox попросив бекенд видалити LV і оновив свій внутрішній стан.

Рішення: Якщо це зазнає невдачі з повідомленням «volume is busy», поверніться до лічильника відкриттів і процесів-утримувачів. Примусове видалення тут породжує нічні сюрпризи.

Завдання 18: Якщо Proxmox не синхронний, знайдіть справжні сироти, скануючи LVM для томів «vm-» без конфігів

cr0x@server:~$ ls /etc/pve/qemu-server | sed 's/\.conf$//' | sort -n | tail -n 5
101
102
104
110
132

cr0x@server:~$ lvs --noheadings -o lv_name pve | awk '{print $1}' | grep '^vm-' | head
vm-101-disk-0
vm-102-disk-0
vm-104-disk-0
vm-999-disk-0-oldsnap

Що це означає: vm-999-... існує в LVM, але немає 999.conf. Це кандидат у сироти.

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

Завдання 19: Підтвердити, чи сирітський кандидат посилається десь у конфігураціях Proxmox

cr0x@server:~$ grep -R "vm-999-disk-0-oldsnap" /etc/pve/qemu-server/ || true

Що це означає: Відсутній вивід свідчить про відсутність посилань у конфігах ВМ.

Рішення: Все одно перевірте, чи він не відкритий і чи не є частиною ланцюга origin/snapshot, що вам потрібен.

Завдання 20: Підтвердити відносини snapshot/origin для кандидата-сироти

cr0x@server:~$ lvs -a -o lv_name,lv_attr,origin,lv_size,data_percent pve | grep -E 'vm-999|Origin'
vm-999-disk-0-oldsnap              Vwi---tz-k  vm-999-disk-0                 100.00g  24.11
vm-999-disk-0                      Vwi-aotz--                                   100.00g  88.02

Що це означає: LV «oldsnap» — це знімок vm-999-disk-0. Якщо vm-999-disk-0 також сирітський, можна видалити обидва — але порядок має значення, і треба перевірити лічильники відкриттів.

Рішення: Видаляйте знімки спочатку, потім origin, якщо немає причин робити інакше (і якщо є докази).

Завдання 21: Підтвердити, що ніхто не тримає сирітський LV відкритим

cr0x@server:~$ dmsetup info -c /dev/mapper/pve-vm--999--disk--0--oldsnap
Name  Maj Min Stat Open Targ Event  UUID
pve-vm--999--disk--0--oldsnap 253 22 L--w 0 1 0 LVM-0bqVtQyS2L3kVJrQ9xF5jH1gYd2nM3p

Що це означає: Лічильник Open = 0. Добре.

Рішення: Можете видаляти, але робіть це так, щоб зберегти консистентність метаданих LVM і полегшити аудит.

Завдання 22: Видалити сирітський LV через LVM напряму (тільки після доказів сирітства)

cr0x@server:~$ lvremove -y pve/vm-999-disk-0-oldsnap
Logical volume "vm-999-disk-0-oldsnap" successfully removed.

Що це означає: LV-знімок видалено. Якщо це був залишок, ви повинні побачити зниження використання thin pool з часом (інколи не миттєво, якщо відкладані discard-операції).

Рішення: Перевірте стан пула і метадані. Якщо метадані залишаються критично високими — заплануйте розширення метаданих або вікно для глибшого прибирання.

Завдання 23: Переперевірити стан thin pool після очищення

cr0x@server:~$ lvs -o lv_name,data_percent,metadata_percent pve/thinpool
LV       Data%  Meta%
thinpool 69.90  88.40

Що це означає: Метадані впали з 92% до 88%. Це має значення. Полегшення метаданих часто важливіше за сирі дані, коли видалення зазнають невдач.

Рішення: Якщо метадані все ще високі — продовжуйте очищення знімків і розгляньте розширення thin metadata.

Завдання 24: Розширити метадані thin pool (обережно), коли ви близько до краю

cr0x@server:~$ lvdisplay pve/thinpool | grep -E 'LV Size|Pool metadata'
LV Size                7.30 TiB
Pool metadata          thinpool_tmeta

cr0x@server:~$ lvs -o lv_name,lv_size pve | grep thinpool_tmeta
thinpool_tmeta  16.00g

cr0x@server:~$ lvextend -L +4G pve/thinpool_tmeta
Size of logical volume pve/thinpool_tmeta changed from 16.00 GiB (4096 extents) to 20.00 GiB (5120 extents).
Logical volume pve/thinpool_tmeta successfully resized.

cr0x@server:~$ lvconvert --repair pve/thinpool
Attempting repair of thin pool pve/thinpool
Thin pool pve/thinpool repaired

Що це означає: Ви збільшили ємність метаданих і відремонтували/оновили структури thin pool. В залежності від середовища, вам може не знадобитися --repair, якщо пул не скаржиться, але масштабування метаданих — стандартний клапан зниження тиску.

Рішення: Якщо у VG немає вільних екстентів — зупиніться і плануйте розширення сховища. Розширення метаданих у «немає місця» — не хитрий трюк; це шлях перетворити попередження в простій.

Завдання 25: Перевірити інвентар Proxmox після ручних змін в LVM

cr0x@server:~$ pvesm list local-lvm | grep -E 'vm-999|oldsnap' || true

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

Рішення: Краще, щоб Proxmox був актором видалень. Якщо ви мусите робити ручні видалення LVM — після цього перевіряйте інвентар і чистіть конфігурацію.

Жарт #2: LVM-thin — як ящик із мотлохом: все поміщається, поки вам не треба знайти одну конкретну річ, і вона тримає ще три інші заручниками.

Три корпоративні міні-історії (як це йде не так у реальному житті)

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

Середня компанія використовувала кластер Proxmox для внутрішніх сервісів: билд-ранери, кілька застарілих додатків і кілька «тимчасових» ВМ, що пережили три реорганізації. Знімки масово застосовували перед вікнами оновлень. Бекенд був LVM-thin на швидких SSD, бо «просто й локально».

Під час планового оновлення ядра інженер припустив, що видалення знімка завжди операція з метаданими і тому майже миттєва. Вони поставили у чергу видалення десятків старих знімків по кількох ВМ, поки резервні копії також йшли в режимі знімків. Система не впала одразу; вона просто стала повільною. Дуже повільною.

Метадані thin pool піднялись у високі 90-ті. LVM почав видавати попередження, далі пул перейшов у режим тільки для читання, щоб захиститись. Це був момент, коли «видалити знімки, щоб звільнити місце» перестав бути опцією, бо саме звільнення вимагало записів у метадані.

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

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

Міні-історія 2: Оптимізація, що дала зворотний ефект

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

Потім почались «випадкові» відмови: іноді знімки не видалялися, іноді використання thin pool не падало, іноді LV залишалися «зайнятими» набагато довше після завершення завдання резервного копіювання. Люди підозрювали баги Proxmox, потім баги ядра, потім «можливо прошивку SSD». Звичний тур.

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

Вони «оптимізували» себе в систему, де очищення не встигало за створенням. Головна помилка не в паралелізмі як такому; а в тому, що вони додали паралелізм без запобіжників, прив’язаних до здоров’я thin pool. Виправлення — обмежити паралельність залежно від відсотка метаданих і рознесення операцій у часі. Резервні копії стали трохи довшими, але кластер перестав грати у рулетку зі сховищем.

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

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

Одного тижня аудит виявив кілька LV, яких не було в жодній конфігурації ВМ. Ніхто не панікував. Вони зробили, як у рукописі: перевірили лічильник відкриттів, перевірили завдання реплікації/резервного копіювання, підтвердили відносини origin, потім запланували видалення на наступне вікно.

Через два дні вузол впав через не пов’язану апаратну проблему. Під час відновлення вони виявили, що сирітські LV походили від попередньої напіввдалої міграції. Якби ті LV залишилися, вони б штовхнули метадані майже до краю під час відновлювального навантаження. Натомість голова метаданих була, і відновлення пройшло нудно. Нудно — найвища похвала в опсах.

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

Чеклісти / покроковий план: безпечне очищення залишків LVM-thin

Ось план, який я дав би на виклик, щоб виправити це без імпровізації. Мета: видалити завислі знімки та сирітські LV без випадкової втрати даних або переведення thin pool у read-only.

Чекліст A: Стабілізувати пацієнта

Заморозити створення нових знімків. Призупиніть завдання резервного копіювання та будь-яку автоматизацію, що створює знімки.
Перевірити відсоток метаданих thin pool. Якщо він дуже високий, вважайте кожну операцію ризикованішою й повільнішою.
Визначити, чи ВМ(и) можна зупинити. Якщо можна — вирішите проблему «busy» швидше й безпечніше.
Підтвердити, що немає вже поточного збою зберігання. Якщо пул read-only або повідомляє помилки — зупиніться і переведіть у режим інциденту.

Чекліст B: Спочатку віддавайте перевагу нативному видаленню Proxmox

Перерахуйте знімки командою qm listsnapshot <vmid>.
Спробуйте видалити через qm delsnapshot.
Якщо не вдається — прочитайте лог завдання і зафіксуйте точну назву LV та повідомлення про помилку.
Якщо повідомляє «busy» — знайдіть відкритих утримувачів і видаліть утримувача, а не LV.

Чекліст C: Коли стан неконсистентний — звірте перед видаленням

Перерахуйте LVM-томи для ідентифікатора ВМ за допомогою lvs.
Пошукайте посилання у конфігах Proxmox на кандидатні LV.
Перевірте відносини snapshot/origin і лічильник відкриттів.
Лише після цього використовуйте pvesm free або lvremove.

Чекліст D: Порядок операцій для ручного очищення (безпечний дефолт)

Зупиніть ВМ, якщо можливо (або щонайменше зупиніть завдання резервного копіювання/реплікації).
Видаліть знімки спочатку (thin snapshot LV, які мають origin).
Потім видаліть справді не використані/сирітські LV.
Перевірте метадані thin pool. Якщо ще високі — розгляньте розширення метаданих або план комплекснішого прибирання.
Запустіть ВМ назад і проведіть швидку перевірку цілісності на рівні гостя, якщо ви робили щось інвазивне.

Чекліст E: Якщо метадані thin pool критично високі

Зупиніть створення знімків (резервні копії, розклади знімків, міграції, що роблять знімки).
Звільніть легкі перемоги: видаліть очевидно старі знімки на некритичних ВМ першими.
Якщо є вільні екстенти — розширте thin metadata (thinpool_tmeta).
Тільки після цього намагайтесь більш інтенсивного очищення, як масове видалення знімків.

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

1) «Видалення знімка зависає назавжди»

Симптом: Завдання Proxmox працює довго; сховище зайняте; в решті — тайм-аут.
Корінна причина: Тиск на метадані thin pool і/або сильна паралельна активність зі знімками; видалення виконує реальну роботу.
Виправлення: Зменшити паралелізм, призупинити резервні копії, перевірити відсоток метаданих. Якщо високий — розширити метадані і обрізати знімки меншими партіями.

2) «TASK ERROR: contains a filesystem in use» або «device busy»

Симптом: lvremove зазнає невдачі; Proxmox повідомляє про зайнятий том.
Корінна причина: qemu або інструменти резервного копіювання тримають dm-пристрій відкритим.
Виправлення: Використайте lsof/dmsetup info, щоб ідентифікувати утримувачів; зупиніть завдання або ВМ; повторіть нативне видалення Proxmox.

3) «Знімок не показано в UI, але простір все ще зайнятий»

Симптом: Немає знімків у qm listsnapshot, але thin pool залишається повним; LVs видно в lvs.
Корінна причина: Сирітські thin LV внаслідок часткових збоїв (міграція, резервне копіювання, збій під час видалення).
Виправлення: Звіртесь: скануйте LVM на томи з префіксом vm-, grep-айте конфіги, перевірте лічильник відкриттів і видаліть через pvesm free або lvremove.

4) «Не можу створити знімки більше»

Симптом: Створення знімка не вдається; помилки про thin pool або недостатній простір.
Корінна причина: Метадані thin pool заповнені (частіше ніж дані в середовищах із інтенсивними знімками).
Виправлення: Розширити thinpool_tmeta, якщо можливо; обрізати знімки; ввести ліміти на кількість знімків на ВМ.

5) «Proxmox показує ‘unused’ диски назавжди»

Симптом: Конфіг ВМ накопичує unused0, unused1; сховище ніколи не звільняється.
Корінна причина: Від’єднання без видалення; обережні дефолти; або оператори уникають руйнівних дій.
Виправлення: Аудит qm unused, підтвердьте, що диски не потрібні, потім видаліть посилання в конфігах і звільніть томи через pvesm free.

6) «Після ручного lvremove Proxmox все ще думає, що том існує»

Симптом: UI показує фантом; операції падають з «volume does not exist» або схожими невідповідностями.
Корінна причина: Залишились посилання в конфігурації (unusedX або записи дисків), або кеш інвентаря Proxmox не оновився.
Виправлення: Видаліть посилання з конфігу ВМ через qm set --delete; перевірте через pvesm list.

FAQ

1) Чи безпечно видаляти LVM-thin знімки поки ВМ працює?

Іноді так — коли Proxmox створив знімок і видаляє його у нормальному потоці. Якщо LV «busy», безпечна відповідь — «зупиніть ВМ або завдання, що тримає його». Не боріться з відкритими пристроями.

2) Чому метадані thin pool заповнюються швидше за дані?

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

3) Якщо `qm listsnapshot` пустий, чи можуть все ще бути знімки?

Так. Proxmox відстежує знімки у стані конфігурації; LVM відстежує thin-томи знімків. Якщо видалення або міграція частково провалилися, LVM може зберегти томи-знімки, які Proxmox більше не посилає.

4) Який найбезпечніший спосіб видалити сирітський LVM thin LV?

Спочатку доведіть, що він не посилається: grep-ніть конфіги Proxmox, перевірте ланцюги origin, підтвердьте лічильник Open = 0. Потім видаляйте через pvesm free, якщо Proxmox знає про нього, інакше через lvremove.

5) Чи можна просто перезавантажити вузол, щоб очистити «device busy»?

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

6) Чому використання thin pool не впало після видалення знімків?

Відновлення простору може відкладатися через discard-поведінку, внутрішній облік thin pool і поточні записи. Також, якщо знімок утримував унікальні блоки, які досі посилаються звідкись ще — ви не отримаєте стільки місця, скільки очікували.

7) У чому різниця між «unused disk» і «snapshot leftover» у термінах Proxmox?

«Unused disk» — це посилання в конфігурації Proxmox на том, не приєднаний до ВМ. «Snapshot leftover» зазвичай — LVM LV, що існує без відповідного запису знімка у Proxmox (або навпаки).

8) Розширити метадані thin pool чи просто видаляти більше знімків?

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

9) Як запобігти цьому в майбутньому?

Обмежуйте кількість і час життя знімків, лімітуйте паралельність резервних завдань залежно від відсотка метаданих thin pool і регулярно звіряйте інвентар Proxmox та LVM. І перестаньте дозволяти «тимчасовим» знімкам ставати постійними квартирантами.

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

Коли знімки Proxmox не видаляються, проблема рідко в «зламаній кнопці». Майже завжди це одна з трьох речей: застарілий лок/завдання, thin pool під тиском метаданих або відкритий пристрій, який LVM справедливо відмовляється руйнувати.

Робіть швидку діагностику в порядку. Використовуйте нативні методи Proxmox для видалення, коли можливо. Коли мусите діяти вручну — звіряйте стан перш ніж видаляти, перевіряйте лічильники відкриттів і дотримуйтесь правильного порядку видалень. І подаруйте собі профілактику: введіть TTL для знімків, обмежте паралельність і моніторте метадані thin pool як SLO першого класу.