Datastore is in use | virtualware.ru

Очень часто в практике администраторов 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.