Proxmox local-lvm на 100%: знайдіть, що з’їло ваш thin pool і виправте це

January 7, 2026 • February 3, 2026 • Читання: 6 хв • Views: 8

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

Local-lvm на 100% — це еквівалент Proxmox відмови підсилювача керма: усе виглядає нормально до того моменту, як перестає бути нормальним. ВМ зависають, бекапи падають, а веб-інтерфейс починає виводити помилки, ніби ви тримаєте нагадувальник на максимальному шумі.

Складність полягає не в тому, що закінчилося місце. Важливо чому закінчилося — тонке виділення, снапшоти, орфанні томи, copy-on-write, гостева система, що ніколи не виконує trim, або метадані, які тихо сягнули межі раніше за дані. Ось як знайти, що «з’їло» ваш thin pool, виправити це не погіршуючи ситуацію і запобігти повторенню.

Що «local-lvm» насправді таке (і чому він заповнюється інакше)

На більшості інсталяцій Proxmox за замовчуванням отримаєте два локальні сховища:

local: директорія (зазвичай /var/lib/vz) для ISO, шаблонів, бекапів.
local-lvm: LVM-thin пул, що використовується для дисків ВМ.

Другий — головний винуватець, коли він досягає 100%. Не тому, що це погано — LVM-thin швидкий, простий і підходить для багатьох кластерів — а тому, що це інший тип «обліку місця», ніж класична файлові система.

Thin provisioning: обіцяний простір vs реальні блоки

LVM-thin дозволяє створювати віртуальні томи (thin LV), які заявляють розмір — наприклад 200G — але споживають фізичні блоки в пулі лише при записі. Це і є thin provisioning. Це полегшує overcommit сховища. Це також легко призводить до сюрпризів, коли реальність наздоганяє.

Снапшоти — не безкоштовні, це відкладені рахунки

Снапшоти LVM-thin — це copy-on-write. Сам снапшот починається малим, але кожен блок, що змінюється під час існування снапшоту, має бути скопійований і відслідкований. Інтенсивні операції запису плюс «ми видалимо снапшоти пізніше» = thin pool, що росте як незведений лог-файл.

Дві межі: дані і метадані

Thin pool має простір для даних і простір для метаданих. Будь-який із них у 100% може зіпсувати ваш день. Метадані відстежують, які блоки належать яким thin томам. Якщо метадані заповнені, виділення можуть зазнати невдачі навіть коли дані ще мають місце. Якщо дані заповнені, записи зазнають невдачі навіть коли метадані ще в порядку. Вони ламаються по-різному і потребують різних дій.

Парафраз ідеї, приписаної Werner Vogels (CTO Amazon): Все рано чи пізно виходить з ладу; стійкість приходить від проєктування під цю реальність, а не від її заперечення.

Швидкий план діагностики (робіть це насамперед)

Вам потрібен швидкий сигнал, а не глибока духовна мандрівка по внутрішнім механізмам LVM. Ось найкоротший шлях до «що заповнене, чому і що робити зараз?»

Перш за все: підтвердіть, чи проблема в даних, в метаданих або в обох

Запустіть lvs з полями thin pool. Якщо Data% близько до 100 — треба звільняти блоки або додати місце. Якщо Meta% близько до 100 — треба розширити/ремонтувати метадані і зупинити тригери росту (часто це снапшоти).

Другий крок: ідентифікуйте найбільших споживачів і «мертві» томи

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

Третій крок: зупиніть кровотечу

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

Четвертий крок: оберіть найменш ризикований спосіб відновлення

Видаліть непотрібні снапшоти (швидкий виграш).
Видаліть справді орфанні томи (великий виграш, середній ризик при помилці).
Увімкніть/відключіть TRIM залежно від ситуації (довший виграш).
Розширте thin pool (краще, якщо у вас є вільні PV у VG).

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

LVM існує в Linux ще з ери 2.4, а LVM2 став стандартним підходом, коли дистрибутиви дорослішали, а SAN-мережі стали звичними.
LVM-thin з’явився на початку 2010-х коли Linux потребував тонкого виділення та снапшотів без підключення повного CoW файлового стеку.
Метадані thin pool зберігаються на диску, а не лише в пам’яті; якщо вони пошкоджені або заповнені, ви можете отримати поведінку лише для читання або помилки виділення.
За замовчуванням Proxmox історично розбивав на «local + local-lvm», бо це відповідало типовим робочим процесам ВМ: ISO на файловій системі, диски — на блочному сховищі.
TRIM/Discard для thin provisioning довго був суперечливим через продуктивність та коректність; зараз це краще, але все ще потребує свідомого включення на всіх рівнях.
Снапшоти дорогі в операційному сенсі в майже будь-якій технології зберігання — LVM-thin, qcow2, SAN — бо вони перетворюють перезапис у allocate-and-copy операції.
Виснаження метаданих часто проявляється «різко», бо воно не пропорційне байтам запису; залежить від мапування виділення і активності снапшотів.
Overprovisioning — це бізнес-функція так само, як і технічна: вона підвищує використання, але це ставка, що не все зростатиме одночасно.

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

Нижче — практичні завдання, які можна виконати на вузлі Proxmox. Кожне завдання містить: команду, що означає вивід, і яке рішення з цього випливає. Припустимо, ваш хост Proxmox на Debian і у вас є root або sudo.

Завдання 1: Порівняйте вигляд сховища в Proxmox і реальність

cr0x@server:~$ pvesm status
Name        Type     Status           Total            Used       Available        %
local        dir     active        98.00GB         12.40GB         80.60GB   12.65%
local-lvm    lvmthin active       700.00GB        699.20GB          0.80GB   99.89%

Значення: Proxmox повідомляє, що local-lvm майже повний. Це симптом, а не діагноз.

Рішення: Перейдіть негайно до огляду LVM. Proxmox показує те, що каже LVM; вам потрібно побачити чому воно повне (дані vs метадані, найбільші thin LV, снапшоти).

Завдання 2: Перевірте стан thin pool (дані та метадані)

cr0x@server:~$ lvs -o+lv_size,segtype,data_percent,metadata_percent,lv_attr,origin,pool_lv --units g
  LV                 VG  Attr       LSize   SegType  Data%  Meta%  Origin  Pool
  data               pve twi-aotz-- 650.00g thin-pool 99.85  12.40         data
  root               pve -wi-ao----  60.00g linear
  swap               pve -wi-ao----   8.00g linear

Значення: data — це thin pool. Data% майже 100%, Meta% в нормі. Ви заповнені по даних, а не по метаданих.

Рішення: Перші варіанти відновлення — звільнити блоки (видалити снапшоти/томи) або розширити пул. Ремонт метаданих у вашому випадку не первинна задача.

Завдання 3: Якщо проблема в метаданих — виявити це явно

cr0x@server:~$ lvs -a -o lv_name,vg_name,lv_size,data_percent,metadata_percent,lv_attr --units g
  LV              VG  LSize    Data%  Meta%  Attr
  data            pve 650.00g  78.10  99.60  twi-aotz--
  data_tmeta      pve   4.00g                 ewi-ao----
  data_tdata      pve 650.00g                 ewi-ao----

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

Рішення: Зупиніть активність, яка створює метадані (снапшоти), подумайте про розширення метаданих і плануйте ремонт у разі помилок. Не продовжуйте записувати — так thin pool може бути пошкоджений.

Завдання 4: Знайдіть, які thin томи реально споживають блоки

cr0x@server:~$ lvs -o lv_name,lv_size,data_percent,metadata_percent,lv_attr --units g --sort -data_percent
  LV                      LSize    Data%  Meta%  Attr
  vm-103-disk-0         200.00g   98.50         Vwi-aotz--
  vm-101-disk-0         150.00g   92.10         Vwi-aotz--
  vm-102-disk-0          80.00g   88.40         Vwi-aotz--
  vm-120-disk-0         500.00g   10.20         Vwi-aotz--

Значення: Data% тут — це відсоток виділених блоків по відношенню до віртуального розміру thin LV. Ті, що близькі до 100%, фактично споживають реальний простір пулу.

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

Завдання 5: Зіставте том з ВМ і конфігом

cr0x@server:~$ qm config 103
boot: order=scsi0;ide2;net0
cores: 4
memory: 8192
name: app-prod-03
scsi0: local-lvm:vm-103-disk-0,size=200G
ide2: local:iso/debian-12.iso,media=cdrom
net0: virtio=DE:AD:BE:EF:10:03,bridge=vmbr0

Значення: vm-103-disk-0 приєднаний до ВМ 103. Тепер можна координувати очищення з власниками додатків (або зі своїм майбутнім «я»).

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

Завдання 6: Перелічіть снапшоти для ВМ (thin снапшоти часто ховаються тут)

cr0x@server:~$ qm listsnapshot 103
`-> pre-upgrade-2024-11-15
    `-> before-hotfix
`-> backup-temp

Значення: Снапшоти існують. Кожен снапшот може закріплювати старі блоки і змушувати CoW на записах, що роздуває використання пулу.

Рішення: Якщо ці снапшоти не потрібні, видаліть їх. Залишайте тільки те, що можете обґрунтувати одним реченням.

Завдання 7: Безпечно видалити снапшот

cr0x@server:~$ qm delsnapshot 103 backup-temp
Deleting snapshot 'backup-temp'...
TASK OK

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

Рішення: Перевірте lvs. Якщо місце не зменшилося, причина може бути в інших об’єктах або TRIM не працює.

Завдання 8: Перевірте на наявність орфанних LV (існують в LVM, але не в конфігах Proxmox)

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

cr0x@server:~$ lvs --noheadings -o lv_name pve | sed 's/^[ \t]*//'
data
root
swap
vm-101-disk-0
vm-102-disk-0
vm-103-disk-0
vm-999-disk-0

Значення: vm-999-disk-0 існує в LVM, але не перелічений Proxmox. Це підозріло.

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

Завдання 9: Перевірте, чи згадується підозрілий LV десь

cr0x@server:~$ grep -R "vm-999-disk-0" /etc/pve/qemu-server /etc/pve/lxc 2>/dev/null || echo "no references found"
no references found

Значення: Конфіги Proxmox не згадують його. Це сильний сигнал, що він орфанний.

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

Завдання 10: М’яке видалення через перейменування LV (купити час)

cr0x@server:~$ lvrename pve vm-999-disk-0 vm-999-disk-0.ORPHANED
  Renamed "vm-999-disk-0" to "vm-999-disk-0.ORPHANED" in volume group "pve"

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

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

Завдання 11: Жорстке видалення орфанного LV для повернення місця

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

Значення: Thin LV видалено. Це звільнить блоки, на які посилався том у thin pool.

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

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

cr0x@server:~$ lvs -o lv_name,lv_size,data_percent,metadata_percent,lv_attr --units g
  LV    LSize    Data%  Meta%  Attr
  data  650.00g  92.30  12.45  twi-aotz--

Значення: Ви відновили простір: з ~99.8% до ~92.3%. Не ідеально, але ви вийшли з категорії «іммінентного краху».

Рішення: Не зупиняйтесь тут. Thin pool не прощає самозаспокоєння. Досягніть стабільного запасу вільного місця (принаймні 10–20% для навантажених вузлів).

Завдання 13: Якщо у VG є вільне місце — розширити thin pool (найчистіше рішення)

cr0x@server:~$ vgs
  VG  #PV #LV #SN Attr   VSize   VFree
  pve   1   5   0 wz--n- 930.00g 280.00g

cr0x@server:~$ lvextend -L +200G /dev/pve/data
  Size of logical volume pve/data changed from 650.00 GiB (166400 extents) to 850.00 GiB (217600 extents).
  Logical volume pve/data successfully resized.

Значення: У вас були вільні екстенти у volume group, і ви використали їх для розширення thin pool.

Рішення: Розширення дає час і зменшує операційний стрес. Але все одно виправте корінь проблеми; інакше ви просто зробили більший відро для тієї ж течі.

Завдання 14: Розширити метадані thin pool, якщо Meta% високий

cr0x@server:~$ lvextend --poolmetadatasize +2G /dev/pve/data
  Size of logical volume pve/data_tmeta changed from 4.00 GiB (1024 extents) to 6.00 GiB (1536 extents).
  Logical volume pve/data_tmeta successfully resized.

Значення: Більше місця для метаданих thin pool. Часто потрібно при великій кількості снапшотів або багатьох thin томах.

Рішення: Якщо ви були вище за Meta% > 90%, зробіть це швидко. Потім зменшіть активність, що створює метадані, щоб не заповнити нові метадані теж.

Завдання 15: Перевірте, чи увімкнені discards на рівні thin pool

cr0x@server:~$ lvs -o lv_name,lv_attr,discards,zero
  LV    Attr       Discards  Zero
  data  twi-aotz-- passdown  yes

Значення: passdown означає, що discards з thin LV можуть передаватися в пул. Це добре для звільнення місця, якщо гість справді видає discards.

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

Завдання 16: Запустіть fstrim у Linux-гості (де відбувається реальне звільнення)

cr0x@server:~$ qm guest exec 103 -- fstrim -av
/boot: 0 B (0 bytes) trimmed
/: 24.6 GiB (26411479040 bytes) trimmed

Значення: Гість повідомив стеку зберігання, які блоки більше не використовуються. Якщо все налаштовано правильно (virtio-scsi + discard увімкнено + thin pool passdown), використання thin pool може зменшитись.

Рішення: Якщо trims повертають значну кількість місця — заплануйте їх регулярно (або обережно увімкніть безперервні discards). Якщо trims постійно повертають 0 B — є розрив у конфігурації.

Завдання 17: Якщо підозрюєте, що пул «застряг», перевірте dmesg і помилки thin

cr0x@server:~$ dmesg | tail -n 20
[12345.678901] device-mapper: thin: 253:2: reached low water mark of 32768 blocks
[12345.678950] device-mapper: thin: 253:2: no free space for data block

Значення: Ядро thin target скаржиться на низький запас блоків / відсутність вільних даних. Якщо пише про метадані — це інша аварійна ситуація.

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

Завдання 18: Визначте найбільші записи з боку Proxmox (груба триаж)

cr0x@server:~$ iotop -o -b -n 3 | head -n 20
Total DISK READ: 0.00 B/s | Total DISK WRITE: 48.32 M/s
  PID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN  IO>    COMMAND
 8421 be/4 root        0.00 B/s   22.10 M/s  0.00% 99.00%  vzdump --compress zstd 101
 9102 be/4 root        0.00 B/s   15.40 M/s  0.00% 97.00%  kvm -id 103 -name app-prod-03
 7766 be/4 root        0.00 B/s    9.90 M/s  0.00% 88.00%  kvm -id 102 -name db-prod-02

Значення: Бекапи (vzdump) і конкретні ВМ генерують записи. На майже заповненому thin pool сплески записів можуть швидко підштовхнути вас через межу.

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

Жарт 1/2: Thin provisioning — як замовити дієтичну содову з трьома бургерами — технічно можливо, емоційно оманливо.

Знайти, що «з’їло» пул: звичайні підозрювані

Підозрюваний A: снапшоти, які жили занадто довго

Снапшоти призначені бути короткоживучими. «Короткоживучі» означає години або дні, не квартали. Активна ВМ зі старим снапшотом змушує кожен змінений блок копіюватися, і ці блоки залишаються закріпленими, поки снапшот існує.

Практична ознака: пул росте постійно, хоча файлові системи в гості кажуть, що вони стабільні. Інша ознака: qm listsnapshot повертає невелике дерево, яке ховає дорогий CoW податок.

Підозрюваний B: бекапи/відновлення/міграції, що залишили сміття

Proxmox загалом добре чистить за собою. Але якщо вузол впав під час відновлення, перервався під час міграції або людина вбила задачу — можуть залишитися орфанні thin томи. Це реальні споживачі простору і невидимі в щоденному UI, якщо не порівнювати pvesm list з lvs.

Операційна реальність: орфанні томи достатньо поширені, щоб робити «звірку LVM з конфігами Proxmox» стандартним кроком під час інциденту.

Підозрюваний C: гості, які ніколи не виконують discard (TRIM не автоматичний)

Thin pool дізнається про «звільнені» блоки тільки коли проходять discards. Видалення 100 GB файлів всередині гостя не обов’язково звільнить 100 GB у thin pool. Без discard/TRIM пул бачить лише записи, ніколи не забуває алокації і повільно наближається до 100%.

Windows-гості потребують планового «Optimize Drives» (TRIM). Linux-гості — регулярного fstrim або опцій монтування з підтримкою discard. Також віртуальний диск/контролер має підтримувати це, і Proxmox не повинен його блокувати.

Підозрюваний D: qcow2 не там, де треба (або raw зі снапшотами в іншому місці)

На local-lvm (LVM-thin) Proxmox зазвичай використовує raw томи, що добре. Але якщо ви зберігаєте qcow2 в директорії (наприклад local) і робите снапшоти на рівні qcow2, механіка росту інша. Інколи адміни переміщують диски між сховищами і отримують несподівані формати та шари снапшотів.

Правило: не насаджуйте CoW на CoW, якщо ви навмисно не тестуєте страждання.

Підозрюваний E: одна ВМ робить «легітимні», але вибухові записи

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

Підозрюваний F: тиск на метадані від багатьох снапшотів або дрібних алокацій

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

Виправити зараз: безпечні дії відновлення

1) Призупиніть джерело росту

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

cr0x@server:~$ systemctl stop pve-ha-lrm pve-ha-crm 2>/dev/null || true
cr0x@server:~$ systemctl stop cron 2>/dev/null || true

Значення: Це грубий інструмент; застосовуйте з обережністю. У кластерах узгодьте вплив. Мета — зменшити фонові завдання, що створюють записи і снапшоти.

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

2) Видаліть непотрібні снапшоти

Це найбільш ефективний крок, коли причиною є снапшоти. Видаляйте через Proxmox, щоб він коректно очистив ланцюжок.

cr0x@server:~$ qm listsnapshot 101
`-> pre-upgrade
`-> weekly-safety

cr0x@server:~$ qm delsnapshot 101 weekly-safety
Deleting snapshot 'weekly-safety'...
TASK OK

Значення: Видалення снапшоту може зайняти час, якщо ВМ активна і відбувається злиття. На LVM-thin це зазвичай швидше, ніж злиття qcow2, але все ще не миттєво при великому IO.

Рішення: Перевірте використання thin pool після кожного великого видалення. Не видаляйте все підряд, якщо вам потрібна точка відкату для поточної ризикової зміни.

3) Видаліть орфанів (акуратно)

Якщо у вас є томи, не згадані жодним конфігом ВМ — поверніть їх у пул. Якщо невпевнені — перейменуйте спочатку.

4) Розширте пул (якщо можете)

Якщо у VG є вільні екстенти, розширення /dev/pve/data — чисте і малоризикове. Якщо ні — додайте новий диск як PV і розширте VG — пам’ятайте про продуктивність і зони відмов.

cr0x@server:~$ pvcreate /dev/sdb
  Physical volume "/dev/sdb" successfully created.

cr0x@server:~$ vgextend pve /dev/sdb
  Volume group "pve" successfully extended

cr0x@server:~$ lvextend -L +500G /dev/pve/data
  Size of logical volume pve/data changed from 850.00 GiB (217600 extents) to 1350.00 GiB (345600 extents).
  Logical volume pve/data successfully resized.

Значення: Ви збільшили ємність thin pool. Дані отримали негайний «повітря».

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

5) Правильно вирішуйте екстрені ситуації з метаданими

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

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

cr0x@server:~$ lvs -o lv_name,lv_attr,seg_monitor,devices pve
  LV    Attr       Cpy%Sync  Monitor  Devices
  data  twi-aotz--           monitored /dev/sda3(0)

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

Рішення: Якщо Meta% високий — розширьте метадані та зменшіть активність снапшотів. Якщо бачите I/O помилки — зупиніться і плануйте вікно ремонту.

6) Зробіть TRIM реальним (end-to-end)

TRIM корисний лише якщо він проходить через весь стек: файлову систему гостя → блочний шар гостя → віртуальний диск → блочний шар хоста → thin pool.

У Proxmox переконайтеся, що диск використовує контролер з підтримкою discard (virtio-scsi зазвичай підходить). У конфігу ВМ увімкніть discard. Потім заплануйте fstrim в гостях.

Запобігти повторенню: нудні, але ефективні контролі

Запас місця — це політика, а не надія

Thin provisioning — ок. Але тримати thin pool на 90–95% на навантаженому вузлі — погана ідея. Бездоганна зона безпеки залежить від швидкості запису і швидкості відновлення. У більшості продакшн середовищ я рекомендую мати принаймні 15–20% вільних даних на thin pool, що хостить інтенсивні ВМ.

Гігієна снапшотів: ліміти часу, а не почуття

Введіть TTL для снапшотів. Якщо снапшот живе довше, ніж причина його створення — це не «запас», а прихований технічний борг.

Регулярна звірка: LVM vs Proxmox

Раз на місяць (або після будь-якого інциденту з відновленням/міграцією) порівняйте thin томи з конфігами ВМ. Ловіть орфанів, поки вони малі і не під тиском.

План TRIM у гостях

Для Linux-гостей зазвичай достатньо щотижневого fstrim.timer. Для Windows — планова оптимізація (TRIM). Для баз даних узгоджуйте з вікнами обслуговування, щоб уникнути піків IO.

Алерти по Data% і Meta% окремо

Більшість стеків алертингу дивляться лише «використання сховища». Це пропускає метадані. Якщо ви алертите на Data% на 80/90%, але ніколи не дивитеся Meta% — ви стежите за не тією прірвою.

Жарт 2/2: Thin pool на 100% — це спосіб природи нагадати, що «необмежено» завжди було маркетингом.

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

1) Симптом: local-lvm показує 100%, але «df -h» виглядає нормально

Корінь проблеми: local-lvm — блочне сховище; df показує використання файлових систем, змонтованих у хості, а не споживання thin pool.

Виправлення: Використовуйте lvs і pvesm status. Розглядайте Data% і Meta% як основні метрики.

2) Симптом: записи ВМ зазнають невдачі або ФС стає лише для читання під час бекапу

Корінь проблеми: thin pool даних повний; бекап створює піки записів (снапшоти, тимчасові томи, CoW накладні витрати).

Виправлення: Зупиніть бекапи, звільніть місце (снапшоти/орфани) або розширте пул. Потім перезапустіть бекапи з запасом місця.

3) Симптом: пул має місце, але нові виділення не проходять

Корінь проблеми: метадані заповнені (високий Meta%) або помилки метаданих.

Виправлення: Розширте метадані (lvextend --poolmetadatasize) і зменшіть churn снапшотів. Перевірте thin помилки в dmesg.

4) Симптом: ви видалили багато файлів у ВМ, але пул не втратив місця

Корінь проблеми: немає TRIM/discard-проходження; блоки залишаються алоковані в thin pool.

Виправлення: Увімкніть discard end-to-end і запустіть fstrim у гості. Перевірте звільнені байти і зміну використання пулу.

5) Симптом: використання пулу росте, хоча ВМ «байдуже»

Корінь проблеми: снапшоти закріплюють блоки; фонові задачі (ротація логів, антивірус, індексація) перезаписують дані; інструменти бекапу створюють churn снапшотів.

Виправлення: Видаліть старі снапшоти, зменшіть churn задач і не зберігайте «вічні» снапшоти на продакшн thin pool.

6) Симптом: пул заповнився «за ніч» після розширення диска ВМ

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

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

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

Покроково: відновлення від local-lvm на 100% (мінімальний ризик)

Підтвердіть, що заповнене — дані чи метадані (lvs -o data_percent,metadata_percent).
Пауза бекап/відновлення/міграцій, що створюють churn.
Перелік використання дисків по ВМ (LVM thin LV) та ідентифікація найбільших споживачів.
Перевірте снапшоти на найбільших споживачах; спочатку видаліть неважливі снапшоти.
Перевірте використання пулу після кожного видалення.
Пошукайте орфанні томи, порівнявши pvesm list і lvs.
Перейменуйте орфанів як захід безпеки; видаліть після підтвердження.
Якщо у VG є вільне місце — розширте thin pool і/або метадані.
Увімкніть і перевірте TRIM end-to-end; запустіть fstrim у гостях.
Перезапустіть призупинені задачі тільки після відновлення запасу місця.

Операційний чекліст: запобігання повторенню

Алертинг окремо по thin pool Data% і Meta%.
Політика TTL для снапшотів і її примусове виконання (автоматизація допомагає).
Щомісячне сканування орфанів: звірка LVM-томів з конфігами Proxmox.
Щоквартальний перегляд ємності: коефіцієнт overcommit, тренди росту і сценарій «worst-case simultaneous growth».
Розклад TRIM у гостях: перевіряйте реальні звільнені байти, а не добрі наміри.

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

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

Мали невеликий кластер Proxmox з внутрішніми сервісами: билд-агенти, сховище артефактів, кілька баз даних і «тимчасові» тестові середовища, що стали дуже постійними. Команда слідкувала за використанням диска через стандартну метрику хоста: відсоток заповнення файлової системи /. Вона залишалася зеленою.

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

Хибне припущення було простим: «якщо на файловій системі хоста є місце, значить є місце для ВМ». Але local-lvm — окремий thin pool, не пов’язаний з /. Thin pool дійшов 100% пізно в неділю під час нібито тихого вікна бекапу — тихого для людей, не для сховища.

Відновлення було простим, коли вони подивилися в потрібне місце: lvs показав Data% 99.9%. Довгоживучий снапшот на write-heavy базі даних закріплював блоки. Видалення снапшоту звільнило достатньо місця для стабілізації, потім розширили пул і додали алерти по Data% і Meta%.

Культурна зміна була кращою: вони перестали вважати thin provisioning «магічним додатковим сховищем» і почали розглядати його як інструмент планування ємності з явним ризиком. Інцидент не був спричинений LVM-thin; його спричинило припущення, яке ніхто не задокументував і не ставив під сумнів.

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

Інша команда хотіла пришвидшити бекапи. Хтось помітив, що снапшот-орієнтовані бекапи «миттєві» на етапі створення снапшоту, і вирішив робити їх частіше, щоб зменшити RPO. Вони автоматизували снапшот кожну годину для ключових ВМ і зберігали їх два тижні. На папері це виглядало відповідально.

Перший тиждень пройшов нормально. На другий тиждень продуктивність стала дивною: спайки латентності, іноді I/O-прикидання і зростаюче використання сховища, що не відповідало росту застосунків. Thin pool не просто наповнювався; він заповнювався у закономірності, що корелювала з write-heavy пакетними задачами.

Щогодинні снапшоти означали постійне CoW-накладення. «Оптимізація» збільшила ампліфікацію записів, швидше спалила метадані і закріпила старі блоки на два тижні — саме стільки, щоб перетворити нормальний churn у постійні алокації. Вони не зменшили бекапи; вони додали другий механізм збереження в самому шарі зберігання.

Вони повернулися до розумнішого підходу: один короткочасний снапшот під час вікна обслуговування плюс реальні бекапи з перевіреними відновленнями. Частота снапшотів впала, продуктивність стабілізувалася, і thin pool перестав поводитися як повільно надуваючийся балон.

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

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

Одна фінансова команда (та, що робить аудиторам приємно і інженерам трохи нудно) керувала Proxmox для кількох десятків ВМ. Їхній підхід був нецікавий: пороги ємності, правила запасу, планове прибирання. Кожна ВМ мала задокументованого власника. Кожен снапшот — термін придатності.

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

Через два тижні щомісячна «звірка сховища» виявила LV, присутній в LVM, але не згаданий у Proxmox конфігах. Звіт не видалив нічого автоматично; він створив тікет з назвою LV, розміром і часом створення. Хтось перевірив, що він ніде не використовується, і видалив його. Місце повернулося.

Нічого не зламалося. Ніякого авралу. Ніякого зіпсованого вікенду.

Практика не була хитрою. Вона була протилежністю: рутинний аудит з ухилом у бік безпечних дій (перейменування перед видаленням, потім видалення). Саме така нудьга запобігла майбутньому інциденту 100% thin pool у день, коли команда була зайнята іншими катастрофами.

FAQ

Чому local-lvm досягає 100%, коли у ВМ ще є вільне місце всередині?

Тому що використання thin pool відстежує алоковані блоки, а не «вільне місце» в гостевій файловій системі. Видалення файлів у гості може не повернути блоки без TRIM/discard. Снапшоти також можуть закріплювати старі блоки.

Чи local-lvm — це те саме, що LVM на кореневому диску хоста?

Ні. Зазвичай це thin pool LV всередині VG (часто pve), окремий від кореневого LV файлової системи. Різний облік, різні режими відмови.

Що небезпечніше: Data% 99% чи Meta% 99%?

Обидва погані. Метадані на 99% можуть бути підступніші, бо виділення можуть зазнати невдачі несподівано, а відновлення може бути складнішим. Уважайте на будь-який із них як на інцидент.

Чи можна просто видаляти «невикористані диски» з GUI?

Можна видаляти невикористані диски, які Proxmox бачить. Небезпека — томи, що Proxmox не перелічує (орфани). Для них спочатку зробіть звірку конфігів; перейменування перед видаленням — добра безпечна практика.

Чому після видалення снапшоту місце не звільнилося миттєво?

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

Чи увімкнення discard шкодить продуктивності?

Може, залежно від навантаження і підлеглого сховища. У багатьох середовищах достатньо періодичного fstrim, а не постійного discard. Вимірюйте на вашому обладнанні.

Як дізнатися, яка ВМ найбільше споживає місця?

Використовуйте lvs відсортоване за per-LV Data% і розмір, і зіставляйте томи з ВМ через qm config <vmid>. Також перевіряйте снапшоти і бекапи на предмет сплесків записів.

Чи можна зменшити thin LV, щоб повернути місце?

Не безпечно як перший крок. Зменшення віртуального розміру вимагає зменшення файлової системи в гості і ретельних операцій на блоці. Краще видаляти снапшоти/орфанів, використовувати trim або розширювати пул.

Чи варто переносити диски ВМ з local-lvm кудись ще?

Якщо вам потрібна передбачувана реплуатація місця, реплікація і видимість — розгляньте сховища з кращими менеджмент-примітивами або окреме сховище для різних рівнів. Але local-lvm підходить, якщо дотримуватися запасу, TTL для снапшотів і trim.

Який найшвидший крок «мені треба місце зараз»?

Видаліть непотрібні снапшоти і прибравши підтверджені орфанні томи. Якщо у VG є вільне місце — розширення thin pool також швидке і малоризикове.

Висновок: наступні кроки, які вам варто зробити

Коли Proxmox local-lvm досягає 100%, рішення рідко містить щось містичне. Зазвичай це одна з чотирьох причин: снапшоти, що перетримали, орфанні томи, відсутність TRIM або проста нестача ємності. Перемога — у діагностиці якої саме, перш ніж ви почнете видаляти те, про що пошкодуєте.

Зробіть наступне:

Запустіть lvs і зафіксуйте Data% і Meta%. Це ваша «земельна істина».
Видаліть непотрібні снапшоти, починаючи з найактивніших ВМ.
Звірте pvesm list і lvs, видаліть підтверджені орфани (спочатку перейменуйте, якщо обережні).
Розширте thin pool, якщо у вас є вільне місце в VG; розширте метадані, якщо Meta% високий.
Робіть TRIM реальним: увімкніть його всіма рівнями і перевіряйте звільнені байти через fstrim.
Налаштуйте алерти і політику TTL для снапшотів, щоб більше цього не трапилося під тиском.