Короткий ответ

Сначала разделите «файловая система гостя 100%» и «thin pool / local-lvm на хосте кончился». Для гостя: почистить или расширить виртуальный диск qm resize 101 scsi0 +Ng, затем увеличить раздел и ФС внутри VM. Не создавайте новый диск и не копируйте GPT вручную, если можно штатно вырастить существующий том.

Не уменьшайте диск без проверенного backup. Shrink в PVE не равен безопасной урезке NTFS/XFS.

Симптомы и как отличить

Типичная картина:

  • приложения в 101 пишут «нет места», логи systemd/Windows остановились;
  • df -h в Linux-госте — / 100%, или диск C: в Windows 0 байт;
  • хостовый pvesm status зелёный, lvs Data% далеко от 100%;
  • либо наоборот: гость «замер», а на хосте thin 99–100%.

Отличия:

Что видноСкорее не «диск гостя»Куда смотреть
Все VM на local-lvm stallthin poolLVM-thin заполнен
pvesm inactivestorageХранилище недоступно
Места много, всё медленноIOVM работает медленно
inode 100% при свободных ГБгостевые inodeчистить мелкие файлы в госте

Возможные причины

  1. Логи, дампы, backup внутри гостя, Windows Update, journal.
  2. Виртуальный диск изначально мал, данные выросли — нужен resize, не только rm.
  3. Хостовый thin закончился: гость видит IO error, не «0 bytes free» классически.
  4. Снимок на qcow2 раздул файл, GUI показывает большой диск.
  5. Заполнился не root, а /var или отдельный LVM LV в госте.
  6. Квота XFS/project quota, выглядит как ENOSPC при свободном df.

Диагностика

На хосте pve1:

pveversion
qm status 101
qm config 101
qm agent 101 ping
pvesm status
lvs -a -o name,size,data_percent,metadata_percent,pool_lv

Строка scsi0: local-lvm:vm-101-disk-0,size=32G — виртуальный размер. Если agent жив:

qm guest exec 101 -- df -h
qm guest exec 101 -- df -i

В Windows-госте смотрите Disk Management / Get-Volume, не хостовый df.

Сверьте: есть ли место на storage для расширения. qm resize требует свободные гигабайты на local-lvm или rpool.

Решение

Сценарий A. В госте мусор, расширять не нужно

Чистите журналы, temp, старые бэкапы в госте. Не трогайте /dev/sda с хоста. Для journald — vacuum внутри VM. На Windows — Disk Cleanup, не сжатие C: вслепую на SQL-сервере.

Сценарий B. Нужно расширить диск (Linux-гость)

  1. Убедитесь в backup или свежем vzdump.
  2. На хосте увеличьте виртуальный диск (имя шины из qm config, часто scsi0):
qm resize 101 scsi0 +10G
qm config 101 | grep scsi0
  1. В госте: ядро должно увидеть новый размер (echo 1 > /sys/class/block/sda/device/rescan или перелогин SCSI). Затем расширьте раздел (growpart/parted) и ФС (xfs_growfs / или resize2fs). Если в госте LVM — pvresize, lvextend, затем grow ФС.

Не удаляйте раздел 1, чтобы «создать больше». GPT + cloud-init часто уже заложены на grow.

Сценарий C. Windows-гость

После qm resize в госте: Disk Management → Extend Volume на том же диске. Если кнопка серая — посередине recovery/EFI: расширяйте только data-раздел, не ломая EFI. Для системного C: обычно незанятое место должно быть справа от C:.

Сценарий D. Места на storage нет

Сначала освободите хост (LVM-thin) или перенесите диск на другой storage. Не режьте чужие VM.

Сценарий E. Нужно уменьшить диск

Не qm resize 101 scsi0 20G на живой ФС больше целевого размера. Уменьшение: backup → restore на меньший диск или штатные процедуры ФС + virt-resize на копии. Иначе обрежете GPT.

Снимок размера до и после, cloud-init и GPT

Перед qm resize запишите текущий size= из конфига и lsblk внутри гостя. После расширения на хосте гостевой lsblk должен показать больший /dev/sda (или /dev/vda) ещё до grow раздела. Если не показал — rescan SCSI, не второй qm resize.

qm config 101 | grep -E 'scsi0|virtio0|sata0'
qm guest exec 101 -- lsblk -o NAME,SIZE,FSTYPE,MOUNTPOINT
qm guest exec 101 -- cat /etc/os-release

Cloud-init/growpart срабатывает на первом буте, не на каждом resize. На уже установленной ОС growpart нужно вызвать самим. Для LVM в госте порядок фиксирован: PV → LV → ФС. Для XFS только grow, не resize2fs. Для NTFS — diskpart extend после того, как Windows увидела unallocated справа.

Не переносите boot-loader на новый диск «чтобы было просторнее», если можно вырастить scsi0. Смена boot-диска ломает EFI/grub и выглядит как «после расширения не грузится».

Как проверить, что проблема устранена

В госте df -h / проводник: свободные гигабайты. Сервис, который падал на ENOSPC, пишет логи. На хосте:

qm config 101 | grep -E 'scsi0|virtio0'
pvesm status
lvs

Размер size= вырос на запрошенное. Гость после ребута монтируется без fsck-паники. Если расширяли XFS/ext4 — UUID разделов те же.

Если не помогло

  • qm resize ошибка space: нет места в пуле, не «команда не та».
  • Гость не видит новый размер: не тот bus (scsi0 vs virtio0), нужен rescan.
  • Windows «не хватает места» при свободном C:: квота, shadow copies, диск восстановления.
  • После resize гость не грузится: не двигали начало раздела? Откат из backup, не fixboot наугад.
  • Заполняется снова за часы: ищите утечку логов/tmp внутри, не крутите resize каждую неделю без причины.

Профилактика

  • Мониторинг df гостя через agent/Zabbix, не только Data% thin.
  • Диски с запасом под журналы и WSUS.
  • Ротация логов в шаблонах VM.
  • Снимки не как способ «освободить место».
  • Перед расширением — проверка узла и storage.

FAQ

Расширять на горячую можно?

Для virtio-scsi/scsi на PVE 8.x обычно да. Гостевая ОС должна уметь rescan. Критичные БД всё равно лучше в окно.

Почему после +10G в GUI гость всё ещё 100%?

Выросли только виртуальный диск. Раздел и ФС сами не выросли.

Можно ли добавить второй диск вместо resize?

Да, если проще отдать /var на новый том. Не путайте с заменой scsi0 пустым диском.

qm resize vs смена размера в GUI?

Одно и то же API. CLI удобнее для заявки: виден точный прирост.

Гость Linux, но df показывает tmpfs 100% — это диск VM?

Нет. Чистите tmpfs/overlay, не scsi0.