Почему такое расхождение в занятом пространстве хоста/esxi?

Question

[Иван]

Добрый день.
Используется хост под управлением гипервизора esxi.
На данный момент на нем работает 2 виртуальные машины.
У каждой ВМ используются тонкие диски.
Занятое пространство 131гб.

В папке отображается, что диск 127/170.

Но в самой виртуалке отображается, что занято всего 60гб:

Пробовал:
vmkfstools -K name.vmdk
Но не особо то помогла эта команда.
Где зарыта проблема?

Answer 1

[athacker]

Оратор выше прав насчёт причин, но не прав в части способа борьбы с этим. Забить нулями -- это не решение, и никакое место, разумеется, не освободится таким образом. Диски вырастут до предельного размера просто, вот и всё. Да, реально на хранилке такие блоки могут быть помечены как свободные (в зависимости от реализации хранилки, ибо сама по себе Варя не делает zero block detection), но это ничего для вас не поменяет, так как гипервизор будет считать эти блоки ЗАНЯТЫМИ (основываясь на данных от VMFS), несмотря на то, что хранилка будет считать их свободными. И разместить больше данных, чем считает свободными VMFS, вам всё равно не удастся.

Поэтому vmkfstools -K нужно запускать ПОСЛЕ ТОГО, как вы забили нулями всё свободное место на дисках виртуальных машин. Вот тогда оно пройдётся по блокам на датасторе и реально пометит их как свободные. Да, и машина при этом должна быть выключена. И эту операцию (зануление свободного пространства и затем vmkfstools) придётся делать с определённой периодичностью.

Можно обойтись без выключения, но вам нужно будет два датастора (как минимум). При миграции с датастора на датастор в Варе можно указать конвертацию дисков. Соответственно, там процесс такой -- сначала зануляете свободное место, потом мигрируете машину на другой датастор с конвертацией диска в толстый, а затем мигрируете её обратно, конвертируя диски в тонкий. Тогда в процессе обратной конвертации Варя прошерстит все блоки, и нулевые пометит как свободные, сжав диск до его реально используемого объёма. Но это доступно только при двух датасторах и наличии vCenter.

Ну и многое зависит от того, как конкретно вы презентуете хранилище гипервизору. Локальные диски, NFS, блочные устройства (FC, iSCSI) -- имеют свои нюансы работы. Начиная с ESXi 6.0, если СХД умеет thin provision, то на гостевых системах можно включить при монтировании опцию discard. Тогда до хранилки будет долетать команда TRIM/UNMAP, что позволит реально помечать блоки под удалёнными файлами как свободные, это будет понимать и VMFS и хранилка. На локальных дисках и NFS такое не прокатит.

Answer 2

[younghacker]

Во-первых: вывод команды df показывает информацию о смонтированных файловых системах поэтому не видно что там ниже.
Посмотрите сколько видит ядро виртуалки
и сколько выдано для разделов. Сравнивайте размеры в байтах.
fdisk -l

Во-вторых: тонкие диски, это возможность "продать" больше чем есть :)
В реальной эксплуатации польза сомнительна. И это прямой путь к тому чтобы столкнуться с проблемами когда один или несколько хостов будут остановлены потому что они запросили гипервизор выделить место, а выделять нечего.
Как в Linux так и во всех современных Windows имеется возможность растянуть раздел в виртуалке без остановки системы поэтому я выделяю диск немного больше чем нужно в текущий момент с запасом на пару месяцев, и по мере необходимости добавляю.

В-третьих почему бы не дробить диск виртуалки на необходимые "жёсткие" разделы (которые не занимают много места и практически не изменяются жизнедеятельнотью софта),

/boot
/

и "гибкие" разделы куда предварительно нужно "подстелить" lvm. При этом желательно с другого физического (виртуального) диска без разделов (прямо LVM) потому что его затем можно растягивать и перемещать на другие физические тома без даунтайма.

/home
/var/lib/mysql
/var/log/
и так далее

Разумеется LVM стоит подложить и под обычный рутовый раздел.
Таким способом получается сделать настроенную виртуалку которая занимает 10-20 гигабайт и содержит только программы и настройки. А дополнительные разделы для пользовательских данных размещаются на другом диске. Таким образом вы всегда знаете что делать чтобы скопировать систему перед серьёзным апдейтом или данные.

А если уж очень хочется резиновое хранилище которое виртуалки могут использовать по очереди, то я бы это решал через файловые системы примонтированные по сети. Но ни в коем случае не тонкими дисками.

Что касается решения вашей проблемы - я бы искал способ

• увеличить дисковое пространство на сервере (вставить - если есть слоты, или примонтировать через iscsi)
  
• сжать диск виртуалки до нормальных разумных необходимых размеров ()