Что делать, если на datastore не хватает места?

Сначала зафиксируйте имя datastore, доступную и занятую ёмкость, подключённые хосты и VM, чьи файлы на нём размещены. Если datastore недоступен только части хостов, сначала выясните причину доступа, а не освобождайте место. Проверьте, что именно занимает пространство: каталоги VM, VMDK, ISO-образы, логи, активные snapshot и snapshot, требующие консолидации. Также оцените активные операции: резервное копирование, клоны, миграции, развёртывание шаблонов и обслуживание vSAN могут продолжать расходовать ёмкость. Контролируемый способ вернуть запас — штатно удалить ненужный ISO или подтверждённо ненужную VM, завершить жизненный цикл ненужного snapshot, увеличить предоставленную ёмкость либо перенести VM на другой datastore с достаточным резервом. После изменений повторно проверьте свободное место, состояние задач, доступность VM и предупреждения хранилища. В vSAN нужно убедиться, что ёмкости достаточно не только для текущих данных, но и для выполнения политик хранения, восстановления и обслуживания.

Можно ли удалить VMDK или файлы snapshot прямо из datastore?

Нет. Файлы VM на datastore взаимосвязаны: помимо виртуальных дисков VMDK там могут находиться конфигурация VMX, журналы, swap-файлы, файлы состояния, snapshot и изменения snapshot. Удаление одного объекта вручную может нарушить работу VM или сделать невозможной корректную консолидацию снимков. Перед освобождением места установите, какой объект является потребителем пространства: VM, ISO-образ, лог, виртуальный диск или snapshot. Ненужные VM и ISO удаляйте только после подтверждения их назначения. Для snapshot применяйте согласованную штатную процедуру vSphere, а не удаление delta-файлов из datastore. Если причина роста пространства неясна, сначала соберите сведения о VM и её снимках средствами vSphere.

Почему после snapshot на datastore быстро заканчивается место?

Потому что snapshot не является неизменяемой полной копией диска: при изменениях в гостевой ОС растут delta-файлы. Место особенно быстро расходуется при длительном снимке, интенсивной записи, цепочке snapshot или незавершённой консолидации. Удаление и консолидация также могут потребовать свободного рабочего пространства.

Поможет ли RAID на локальном datastore запустить VM на другом хосте?

Нет, RAID защищает от отказа отдельного диска, но не делает локальный datastore общим и не заменяет второй хост, резервное копирование или защиту от ошибок администратора. При отказе ESXi-хоста VM и её локальные файлы обычно недоступны, пока хост не восстановят или данные не восстановят другим предусмотренным способом.

Можно ли сделать vMotion, если datastore доступен только одному хосту?

Нет, для переноса работающей VM на другой хост без перемещения её файлов datastore должен быть доступен обоим участникам. Также нужны совместимые хосты, сеть, права на vMotion и корректная конфигурация. Само наличие общего хранилища не запускает миграцию автоматически, но является одним из необходимых условий.

Нужно ли проверять совместимость дисков для vSAN, если ESXi их видит?

Да, обнаружение дисков ESXi не подтверждает их поддержку для vSAN. До развёртывания нужно сверить серверы, контроллеры, накопители, сетевые адаптеры, firmware и выбранную архитектуру OSA или ESA с VMware Compatibility Guide и документацией VMware/Broadcom для используемого релиза.

Datastore и VMware vSAN: как организовать хранение виртуальных машин

Datastore — логическое хранилище, которое видит ESXi и на котором лежат файлы виртуальных машин. VMware vSAN не является альтернативой понятию datastore: это технология распределённого хранения, создающая общий vSAN datastore из локальных накопителей хостов кластера. Выбор между локальными дисками, внешним общим хранилищем и vSAN зависит от требований к доступности, миграциям, производительности, сети и эксплуатации, а не только от доступной ёмкости.

Datastore: логическое пространство, а не физический диск

В vSphere datastore — это представление хранилища для VMware ESXi. Основой могут быть локальное блочное устройство или логический том RAID-контроллера, LUN внешней SAN, экспорт NAS по NFS, контейнер хранения vVol на совместимом массиве либо объединённые накопители vSAN-кластера. Поэтому datastore не следует отождествлять с отдельным SSD, RAID-массивом, NAS-устройством или SAN: это уровень, на котором vSphere размещает и учитывает файлы.

Одна виртуальная машина обычно занимает не один файл. На datastore могут находиться её конфигурация VMX, виртуальные диски VMDK, журналы, файлы состояния, swap-файл ESXi, файлы снимков и их изменения. При отдельных операциях создаются также файлы памяти VM. Кроме VM, на datastore нередко загружают ISO-образы, шаблоны и служебные файлы. Набор файлов зависит от состояния VM, настроек и выполняемых задач.

Не удаляйте файлы VM вручную

Удаление VMDK, VMX, файлов snapshot или служебных файлов напрямую из браузера datastore либо через оболочку ESXi может сделать VM неработоспособной и осложнить восстановление. Сначала нужно установить назначение объекта и использовать штатные операции vSphere. Особенно опасно удалять файлы с похожими именами у VM со снимками.

Какие datastore встречаются в vSphere

В актуальной документации VMware/Broadcom обычно рассматриваются VMFS, NFS, vVol и vSAN datastore. Доступность конкретного типа и связанных функций зависит от релиза vSphere, подключённой системы хранения, драйверов, конфигурации и прав на использование компонентов.

Тип datastore описывает способ предоставления хранилища ESXi, а не сам по себе уровень отказоустойчивости.

Тип datastore	Что предоставляет ESXi	Типичный сценарий
VMFS	Файловую систему VMware поверх блочного устройства: локального диска, логического тома RAID-контроллера или предоставленного LUN.	Один хост с локальным хранилищем либо несколько хостов с общим блочным LUN.
NFS datastore	Файловое хранилище, экспортированное NAS-системой по NFS.	Общий datastore для нескольких хостов, когда в инфраструктуре предусмотрено NFS-хранилище.
vVol	Представление компонентов VM как отдельных объектов на поддерживающем массиве с управлением через политики.	Интеграция vSphere с массивом, поддерживающим vVol и соответствующий VASA Provider.
vSAN datastore	Общий распределённый datastore из локальных накопителей участников vSAN-кластера.	Гиперконвергентный кластер, где вычисления и хранение размещены на одних ESXi-хостах.

VMFS может быть как локальным, так и общим: определяющим является доступ хостов к базовому блочному устройству. NFS обычно уже является общим ресурсом NAS. vVol переносит часть управления объектами VM на массив. Настройка подключений iSCSI, FC и NFS выходит за рамки статьи; здесь предполагается, что блочное устройство или NFS-экспорт уже предоставлены ESXi.

Почему VMware vSAN создаёт datastore, а не заменяет его

Гиперконвергентная инфраструктура объединяет вычислительные ресурсы и локальные накопители узлов под программным управлением. vSAN — частный пример программно-определяемой распределённой виртуализации хранилища в экосистеме VMware. После настройки кластера vSAN предоставляет ESXi общий vSAN datastore; именно его выбирают при создании VM, размещении дисков или ISO.

Доступность объектов vSAN задаётся политиками хранения через SPBM: политика определяет требования к размещению и допустимым отказам в пределах возможностей кластера. Следовательно, вопрос «datastore или vSAN» сформулирован неточно. Корректнее сравнивать datastore на локальных дисках, datastore внешней СХД и vSAN datastore.

У vSAN существуют архитектуры vSAN OSA и vSAN ESA. В OSA локальные устройства организуются в дисковые группы с кэш-устройством и устройствами ёмкости. В ESA используются NVMe-накопители и пул хранения хоста без дисковых групп классической OSA. Архитектуры отличаются требованиями к устройствам, сети, конфигурации и поддерживаемым сценариям.

Проверка совместимости vSAN обязательна

До выбора vSAN сверяют конкретные серверы, контроллеры, накопители, сетевые адаптеры, firmware и целевую архитектуру OSA или ESA с VMware Compatibility Guide и официальной документацией VMware/Broadcom для используемого релиза. Поддержка отдельных вариантов развёртывания, включая число узлов и варианты отказоустойчивости, определяется этой документацией и не должна выводиться только из того, что ESXi обнаружил диски.

Локальный datastore, внешнее общее хранилище и vSAN

Ни одна из моделей не является универсально лучшей: сравнивают последствия отказов и возможности конкретной инфраструктуры.

Модель	Где находятся данные	Что происходит при отказе хоста	Последствия для миграции и эксплуатации
Локальный datastore	На дисках одного ESXi-хоста, обычно как VMFS на локальном блочном устройстве.	VM и её локальные файлы обычно недоступны, пока не восстановлен хост или данные не восстановлены иным предусмотренным способом.	Для переносимости VM требуется отдельный процесс переноса данных; кластерные возможности ограничены отсутствием общего хранилища.
Внешнее общее хранилище	На SAN, NAS или массиве, доступном нескольким ESXi-хостам.	Отказ хоста не обязательно означает потерю доступа к файлам VM, если СХД и пути доступа продолжают работать.	Облегчает миграции между хостами и перезапуск VM на другом узле, но создаёт зависимость от СХД и сети хранения.
vSAN datastore	На локальных накопителях нескольких участников vSAN-кластера, распределённо согласно политике.	Результат зависит от политики, числа узлов, состояния сети и доступной избыточности данных.	Даёт общий datastore внутри кластера, но требует контроля совместимости, сети, ёмкости и процедур обслуживания.

Локальный datastore подходит для лаборатории, стенда, периферийного сервера или нагрузки, для которой допустим простой при отказе единственного хоста. Он может быть производительным и простым, но сам по себе не обеспечивает переносимость VM между узлами.

Внешнее общее хранилище отделяет слой хранения от ESXi-хостов. Это удобно, когда СХД уже существует или когда нужно независимо масштабировать вычисления и хранение. Проекту нужны резервирование путей, оценка задержек, пропускной способности и отказоустойчивости самой СХД.

vSAN уместен, когда кластер строится как единая система из одинаково или совместимо оснащённых узлов и команда готова сопровождать сеть хранения, политики, ребалансировку и жизненный цикл устройств. Его ёмкость нельзя оценивать простой суммой дисков: часть ресурсов требуется политикам доступности, операциям восстановления, обслуживанию и перераспределению данных.

Как выбрать размещение VM

Один хост. Выбирайте локальный datastore, если остановка VM при отказе сервера приемлема и данные защищаются отдельным резервным копированием. RAID снижает риск отказа отдельного диска, но не заменяет второй хост, backup или защиту от ошибок администратора.
Кластер с перезапуском VM на другом хосте. Обычно требуется хранилище, доступное целевым хостам: внешнее общее или vSAN datastore. Настройки высокой доступности и подготовку кластера рассматривает статья «VMware vSphere HA и DRS: перезапуск VM и балансировка ресурсов».
Работающая VM должна менять хост без переноса её файлов. Нужны совместимые хосты, сеть и datastore, доступный обоим участникам; дополнительно проверяют права на vMotion и конфигурацию. Общее хранилище не включает миграцию автоматически.
Нужно перенести файлы VM между datastore. Оценивают совместимость, свободную ёмкость и доступность Storage vMotion. Детали выбора и переноса — в статье «Миграция виртуальных машин: live migration, V2V и P2V».
Есть разные классы нагрузки. Разносите VM по datastore с подходящими задержками, производительностью, политиками и запасом ёмкости. Не делайте вывод о скорости только по типу SSD или названию СХД: важны весь путь ввода-вывода и профиль нагрузки.

Общее или распределённое хранение не заменяет HA, резервное копирование и отказоустойчивость приложения. HA может перезапустить VM после отказа, но не сохраняет незаписанные данные приложения и не исправляет логическую ошибку внутри гостевой ОС. Snapshot также не является резервной копией; его жизненный цикл разобран в статье «Клоны, шаблоны и снимки виртуальных машин: безопасная работа в vSphere».

Лицензии и доступность функций

Наличие Storage vMotion, vSAN, vVol, Storage DRS и связанных операций зависит от версии vSphere, подписки или редакции, конфигурации и лицензирования. Перед проектированием сверяют официальные матрицы возможностей VMware/Broadcom и права конкретной поставки; контекст актуальной модели поставки — в статье «Лицензирование VMware vSphere, ESXi и vCenter: редакции, подписки и ограничения».

Почему datastore заполняется быстрее ожидаемого

При thin provisioning виртуальному диску или LUN может быть назначена логическая ёмкость, превышающая физически свободное место. Пока гостевая ОС не записывает данные, это незаметно; затем несколько VM способны одновременно потребовать реальную ёмкость. Thick Provisioning резервирует заявленный объём заранее, но не отменяет рост логов, ISO, snapshot и служебных файлов.

Снимок не является неизменяемой копией всего диска: при изменении данных могут расти delta-файлы. Длительный snapshot, интенсивная запись в гостевой ОС, цепочка снимков или не завершившаяся консолидация снимков способны быстро сократить свободное место. Операции удаления и консолидации сами могут требовать рабочего пространства, поэтому запускать их на почти заполненном datastore рискованно.

Нехватка места — риск простоя и ошибок операций

При заполнении VMFS, NFS или vSAN datastore создание VM, запись в виртуальные диски, создание snapshot, включение VM и операции консолидации могут завершиться ошибкой. Ввод-вывод работающей VM также может приостановиться или завершаться ошибками, что способно сделать прикладной сервис недоступным. Конкретное поведение зависит от типа datastore, версии, выполняемой операции и состояния хранилища. На vSAN дополнительно влияют политики хранения, отказ устройств, ребалансировка и обслуживание: свободная физическая ёмкость не равна гарантированно доступной ёмкости для всех политик.

Что делать, если не хватает места на datastore

Безопасная последовательность при нехватке ёмкости

Задача — освободить или добавить место без случайного повреждения VM и без запуска операций, для которых уже нет рабочего пространства.

1
Определите проблемный datastore и затронутые VM
В инвентаре vSphere зафиксируйте имя datastore, его доступную и занятую ёмкость, подключённые хосты и VM, чьи файлы на нём размещены. Ожидаемый результат — понятен владелец риска: один локальный хост, общая СХД или vSAN-кластер. Если datastore недоступен части хостов, сначала локализуйте проблему доступа, а не удаляйте данные.
2
Проверьте фактических потребителей места
Сопоставьте занятое пространство с каталогами VM, размером виртуальных дисков, ISO, логами и наличием активных либо требующих консолидации snapshot. Ожидаемый результат — список объектов, рост которых подтверждён, а не предположение по имени файла. Если причина неясна, не удаляйте неизвестные объекты: соберите сведения о VM и её снимках штатными средствами vSphere.
3
Оцените ближайшие операции
Проверьте активные задачи: backup, создание клонов, снапшоты, развёртывание шаблонов, миграции и обслуживание vSAN. Ожидаемый результат — исключены операции, которые продолжают расходовать место. Если важная задача уже идёт, оцените её состояние и требования по документации используемого продукта, прежде чем отменять её.
4
Выберите контролируемый способ вернуть запас
Предпочтительные варианты — штатно удалить ненужный ISO или подтверждённо ненужную VM, завершить жизненный цикл ненужного snapshot по согласованной процедуре, расширить предоставленную ёмкость либо перенести VM на datastore с достаточным запасом. Ожидаемый результат — план содержит источник места, объём, окно работ и проверку после операции. Пошаговый перенос рассматривается в статье о миграции VM, а работа со snapshot — в отдельной статье о снимках.
5
Для vSAN проверьте политики и состояние кластера
Сверьте использование ёмкости с назначенными политиками, состоянием объектов, устройствами, ребалансировкой и планируемым обслуживанием. Ожидаемый результат — добавляемая или высвобождаемая ёмкость достаточна не только для текущей записи, но и для выполнения требований политик. При предупреждениях о несоответствии политики, недоступных компонентах или нехватке места для восстановления действуйте по официальной документации VMware/Broadcom для вашей архитектуры OSA или ESA.
6
Подтвердите результат и настройте наблюдение
После изменения повторно проверьте свободное пространство, состояние задач, доступность затронутых VM и предупреждения хранилища. Ожидаемый результат — на datastore есть согласованный запас для обычного роста и предстоящих операций. Если место продолжает быстро уменьшаться, найдите источник записи в конкретной VM или операции, а не увеличивайте объём бесконтрольно.

Для vSAN нельзя применять универсальный процент свободного места как правило для любой среды. Нужный резерв определяется архитектурой, политиками, фактической раскладкой объектов, числом отказов, возможностью замены устройств, ребалансировкой и планом обслуживания. Официальные рекомендации по контролю ёмкости следует сверять с документацией VMware/Broadcom для используемого релиза и архитектуры.

Интерфейс и названия пунктов могут отличаться

Названия экранов, статусов, объектов и доступных действий в vSphere Client, vCenter, ESXi и vSAN зависят от релиза, подписки, архитектуры OSA или ESA и конфигурации. Для изменения хранилища, политик или состава vSAN-кластера используйте официальное руководство VMware/Broadcom для своей версии; статья описывает логику выбора и безопасную последовательность проверки, а не фиксированный путь по интерфейсу.

Термины в статье

Виртуализация: Технология абстрагирования физических вычислительных ресурсов, позволяющая создавать виртуальные серверы, хранилища, сети и другие логические ресурсы.
Гиперконвергентная инфраструктура: Гиперконвергентная инфраструктура — архитектура кластера, объединяющая вычисления, хранение и виртуализацию на узлах с локальными дисками под единым программным управлением.
Клонирование виртуальной машины: Создание копии виртуальной машины как отдельной ВМ; полный клон независим от исходной ВМ, а связанный использует её базовые виртуальные диски.
Консолидация снимков: Консолидация снимков — операция объединения оставшихся файлов изменений снимка с базовыми или родительскими дисками ВМ после удаления снимка либо сбоя очистки.
Снимок состояния: Зафиксированное гипервизором состояние поддерживаемых виртуальных дисков и конфигурации ВМ на определённый момент, иногда также памяти, к которому можно выполнить откат.
Шаблон виртуальной машины: Подготовленный объект платформы виртуализации с образом ОС и заданной конфигурацией для повторяемого развертывания новых виртуальных машин.
Datastore: Логический контейнер хранилища в VMware для размещения файлов виртуальных машин (диски, конфигурации, логи)
ESXi Shell: ESXi Shell — локальная командная оболочка VMware ESXi для диагностики и администрирования хоста. Удалённый доступ к командной среде предоставляется отдельно включаемой службой SSH.
Guest OS: Операционная система, установленная в виртуальной машине и работающая под управлением гипервизора; не следует путать с хостовой ОС гипервизора типа 2.
RAID: Технология объединения нескольких накопителей в логические блочные устройства для повышения производительности и/или отказоустойчивости в зависимости от RAID-уровня.
SPBM: SPBM — механизм vSphere для назначения ВМ и их дискам политик хранения, выбора совместимых датасторов и контроля соответствия требованиям.
Storage DRS: Storage DRS — механизм VMware для выбора и балансировки хранилищ в кластере datastore по свободной ёмкости и задержке ввода-вывода.
Storage vMotion: Функция VMware vSphere для переноса файлов и виртуальных дисков работающей виртуальной машины между датасторами без её выключения.
Thick Provisioning: Способ выделения виртуального диска, при котором вся его заявленная ёмкость заранее резервируется в хранилище, в отличие от выделения пространства по мере записи.
Thin Provisioning: Метод предоставления логической ёмкости LUN, томам или виртуальным дискам, при котором физическое место выделяется по мере записи, а не резервируется целиком заранее.
vCenter Server: Централизованная система управления инфраструктурой VMware для администрирования множества ESXi хостов из единого интерфейса
Virtual Volumes: Virtual Volumes — модель VMware, в которой виртуальные диски и другие компоненты ВМ представлены отдельными объектами на массиве и управляются политиками хранения.
VMDK: VMDK — формат виртуального диска VMware, в котором данные блочного устройства гостевой ОС хранятся в одном или нескольких файлах.
VMFS: VMFS — кластерная файловая система VMware для блочных хранилищ, формирующая datastore с согласованным доступом нескольких хостов ESXi к файлам ВМ.
vMotion: Технология VMware vSphere для переноса включённой виртуальной машины между хостами ESXi без выключения гостевой ОС; при переключении возможна краткая пауза.
VMware ESXi: VMware ESXi — гипервизор типа 1, устанавливаемый непосредственно на совместимый физический сервер для запуска и управления виртуальными машинами.
vSAN: Программно-определяемое хранилище VMware, объединяющее локальные накопители хостов ESXi в общее распределённое хранилище с управлением через политики.
vSAN ESA: vSAN ESA — архитектура VMware vSAN для кластеров с NVMe-накопителями, объединяющая устройства каждого хоста в единый пул хранения без дисковых групп классической архитектуры.
vSAN OSA: vSAN OSA — исходная архитектура VMware vSAN, организующая локальные накопители хоста в дисковые группы с кэш-устройством и устройствами ёмкости.
vSphere: Платформа виртуализации VMware, включающая гипервизор ESXi и средства управления vCenter для корпоративной инфраструктуры