«Datastore is in use» или гадание на кофейной гуще

Очень часто в практике администраторов vSphere возникает задача освободить какой-либо датастор от нагрузки и отключить его от хостов ESXi для тех или иных целей, например, для обслуживания или утилизации СХД. И очень часто бывает так, что для того что бы сделать Unmount датастора с хостов, недостаточно просто смигрировать с него все виртуальные машины.

Дело в том, что vSphere, а точнее ESXi хосты используют доступные датасторы не только для хранения файлов виртуальных машин, но и для ряда других целей, о которых не всегда знает администратор. В этой статье мы разберем по каким причинам может не получаться отмонтировать датастор от ESXi, и как их ликвидировать.

Все начинается c того что мы как администратор vSphere с помощью Storage vMotion производим миграцию VM одну за другой с нашего хранилища или если наш датастор находиться в Storage Cluster-е мы просто вводим его в Maintenace Mode и ждем пока виртуальные машины разъедутся сами на другие датасторы с помощью SDRS. А по завершению этих операции жмем кнопку Unmount и выбираем из списка хосты от которых мы планируем отмонтировать данный датастор.

Но вот незадача. Появляется одна из нижеперечисленных ошибок:

The Resource is in use.

Cannot remove datastore ‘Datastore Name: <UUID датастора>’ because file system is busy. Correct the problem and retry the operation.

The resource Datastore Name: <UUID датастора> is in use.

Или похожее сообщение. В зависимости от версии vSphere сообщения могут быть разные, но их объединяет контекст того, что хранилище на текущий момент занято (используется чем-то) и не может быть отключено. А вот чем, как правило в сообщениях не упоминается. Разберемся по порядку в причинах.

vCLS VMs

С версии vSphere 7.0u1 у нас появились vCLS виртуальные машины в инфраструктуре, где включен механизм DRS на кластрах. Эти машины берут на себя роль движка DRS и занимаются калькуляцией. Нужно это для того что бы служба DRS не зависела от vCenter. Если vCenter станет недоступным, то это не затронет функционал DRS. Эти машины не занимают много места и деловито перемещаются с хоста на хост в пределах своего кластера, особо никого не напрягая.

Но в то же время наличие данных VM в некотором роде усложнило администратором vSphere работу, так эти машины весьма специфичны и многие из функций vSphere с ними не работают. Например, Storage DRS. Что увеличивает количество ручных манипуляций с ними при миграции.

Как упоминалось выше, SDRS не работает с vCLS VMs. Поэтому эти машины не смигрируют с датастора автоматически, когда вы вводите его в Maintenance Mode. Более того, присутствует определенный баг при ручной миграции фалов этих машин с помощью Storage vMotion (когда мы меняем только датастор у этих машин).

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

Снепшоты и ISO образы

Следующее что может нам помешать отмонтировать датастор, это iso образы, которые на нем лежат. Если iso-шники просто там лежат и не подключены ни к одной VM, то никаких неприятностей у нас не будет. Но вот если iso-шник подключен в дисковод к VM, то датастор нам не отцепить.

К счастью такие VM легко определить. Виртуальные машины с подключенными iso образами, расположенными на этом датасторе будут перечислены в разделе VM нашего датастора, хотя на нем не будет ни одного vmdk этой VM. И после того как мы с помощью Storage vMotion смигрировали все VM с этого датастора, подобные VM будут по-прежнему числиться на нем. Нам остается только отключить iso-шники от этих машин.

Бывает так что в CD-ROM таких машин не оказывается никакого iso образа, а VM по-прежнему числиться на проблемном датасторе. Что делать? Это значит у этой машины присутствует снепшот, на момент создания которого к этой машине в CD-ROM был подключен iso образ с нашего датастора. Снепшоты сохраняют не только состояние памяти и vmdk дисков виртуальной машины, но и ее конфигурацию в определенной точке времени. Выход – удалить этот снепшот.

Логи

Ввиду тех или иных обстоятельств иногда приходится настраивать хранения логов ESXi хостов на выделенный датастор. Это может быть, как установка гипервизора на SD/USB карту, так и использование AutoDeploy. У нас не получиться отмонтировать датастор от ESXi, который складывает на него логи. А если отмонтировать очень нужно, то придется решать вопрос с размещением логов.

За размещение логов хоста отвечает настройка Syslog.global.logDir вAdvanced Setting хоста. Данная настройка имеет следующий синтаксис – [<имя датастора>] /<путь>/.

Логи — компонент достаточно важный в инфраструктуре, особенно в продовой. Поэтому рекомендуется настроить их хранение в месте, которое обладает достаточной доступностью. Но в критических ситуациях, когда альтернативного места нет, а датастор вывести всё-таки нужно, можно прибегнуть к тому, чего VMware не рекомендует – настроить размещение логов в памяти хоста. Для этого в Syslog.global.logDir прописываем — «[] /temp/». Но это сугубо временное решение, например, если датастор для хранения логов на короткое время становиться недоступным ввиду обслуживания.

Изменение данной настройки не требуют перезагрузки и вступают в силу немедленно. Поэтому ESXi сразу «отпускает» наш датастор и мы можем продолжить его отключение.

CoreDumps

Так же, как и логи, CoreDump-ы очень важны для диагностики хостов в случае сбоя. Так же как с логами, CoreDump-ы могут быть размещены на датасторах ввиду определенных причин, таких как недостаточное место на установочном носителе или AutoDeploy. И так же, как и с логами, если определенный хост использует датастор для размещения файлов CoreDump, то отмонтировать этот датастор от него не получиться.

CoreDump-ы хранятся в папке vmkdump, которая располагается в корне датастора. И если на датасторе присутствует эта папка, а в ней расположены файлы с расширением «.dumpfile», то это наш случай.

Для начала определяем хосты, от которых не удаётся отмонтировать данный датастор. Затем подключаемся к данным хостам по SSH. Используем команду:

esxcli system coredump file list

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

Что можно сделать?

  • Перенастроить размещение дамп файла на другой датастор
  • Или Dump Collector
  • Отключить хранения дампа на датасторе вообще (что опять же не рекомендовано)

Перенастройка размещения dump-ов на другой датастор

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

esxcli system coredump file add –d <имя датастора> -f <имя файла>

Проверим, создался ли файл.

esxcli system coredump file list

В списке должно присутствовать уже два файла. Теперь активируем новый файл, взамен старого.

esxcli system coredump file set –p <путь до файла> -e

Проверим, прошло ли переключение.

esxcli system coredump file list

И если все нормально и новый файл числиться активным, то можно удалить старый.

esxcli system coredump file remove -f <имя файла> -F

Деактивация и удаление dump файла

Если у нас нет другого датастора для хранения dump-ов хоста, то как вариант можно просто отключить dump файл, оставив хост без места хранения core dump-ов. Конечно это не рекомендуется делать, но как временное решение может подойти.

Сначала деактивируем файл.

esxcli system coredump file set –u

Затем удаляем dump файл.

esxcli system coredump file remove -f <имя файла> -F

Отправка dump-ов в DumpCollector

Один из вариантов – это настроить отправку core dump-ов в CoreDump Collector по сети. CoreDump Collector это служба на борту vCenter для сбора dump-ов при падении ESXi хоста в PSOD. И для начала ее нужно включить на vCenter, а затем настроить отправку dump-ов по сети на ESXi хосте.

Конфигурируем ESXi для отправки Core Dump в коллектор

esxcli system coredump network set --interface-name <vmk#> --server-ipv4 <VC IP> --server-port 6500

Активируем конфигурацию

esxcli system coredump network set --enable true

Проверим конфигурация Core Dump Collector

esxcli system coredump network get

После этого удаляем файл dump-а c дататсора командой из предыдущего раздела. И можно отмонтировать датастор.

HA Herathbeat Datastore

Если датастор задействован как Hearthbeat Datastore в кластере HA, то отмонтировать его не получиться от хостов этого HA кластера. Сначала нужно настроить другой датастор в качестве Heartbeat в замену текущему и перенастроить HA кластер.

SIOC

Включенный Storage I/O Control так же может не дать нам отмонтировать датастор.

Datastore Cluster

Членство датастора в SDRS кластере тоже может предотвратить отмонтирование.

Другие процессы

На ESXi хосте могут работать различные процессы, которые так или иначе могут использовать датастор. Это могут быть сторонние решения, интегрированные с vSphere или какие-нибудь скрипты. Например, sftp процесс, с помощью которого вы просматриваете содержимое датастора, подключившись к ESXi, на предмет того, что еще мешает отмонтировать его (внезапно да?).

Подобные процессы можно идентифицировать с помощью команды:

esxcli storage core device world list -d <naa.xxxxxxxx>

Затем, такие процессы нужно ликвидировать.

На этом все. Надеюсь данная статья облегчит жизнь администраторам vSphere.