Восстанавливаем виртуальные машины с ошибочно инициализированного Datastore. История одной глупости с хэппи-эндом
Файловая помойка в нашей организации крутится на виртуальной машине VMware ESXi 6 под Windows Server 2016. И это не просто помойка. Это сервер файлового обмена между структурными подразделениями: тут и совместная работа, и проектная документация, и папки с сетевых сканеров. В общем, тут вся производственная жизнь.
И вот это вместилище всей производственной жизни стало виснуть. Причем гость мог тихо повиснуть сам, не затрагивая остальных. Мог повесить вслед за собой весь хост и, соответственно, все остальные гостевые машины. Мог повиснуть сам и повесить клиентские службы vSphere: то есть процессы остальных гостей живы, машины исправно работают и отвечают, а вот файлопомойка нет и vSphere Client к хосту не цепляется. В общем, никакой системы выявить не удавалось. Зависания могли произойти днем во время слабой загрузки. Могли ночью во время нулевой нагрузки. Могли ночью во время дифференциального резервного копирования и средней загрузки. Могли в выходные во время полного резервного копирования и высокой нагрузки. И наблюдалась явная деградация ситуации. Сначала это было раз в год, потом раз в полгода. Под конец моего терпения — дважды в неделю.
Я грешил на оперативную память. Но остановить помойку даже в выходные и прогнать Memtest мне не давали. Ждали майских праздников. В майские праздники я прогнал Memtest и… ошибок найдено не было.
Я впал в изумление и решил сходить в отпуск. Пока я был в отпуске — у помойки не было ни одного зависания. А когда в понедельник вышел первый день на работу — помойка висела. Вытерпела полное резервное копирование и аккурат по его окончании повисла. Такая теплая встреча из отпуска подтолкнула меня к решению физически перетащить диски с гостевой машиной в другой хост.
И, хотя давно известно, что в первый день после отпуска нельзя делать ничего серьезного, хотя я всю дорогу на работу настраивал себя не работать, мое возмущение очередным зависанием выбило из головы и настрой, и зароки…
Физические диски были переставлены в другой хост. Подключение на горячую. В настройках хранилищ на вкладке Drives появляются диски. На вкладке Datastores хранилища на этих дисках — нет. Refresh — не появляются. Ну и, разумеется, первый порыв — Add Storage. Мастер добавления рассказывает, что он поддерживает. Конечно поддерживает и VMFS. Я и не сомневался. Беглый просмотр сообщений мастера на каждом шаге: Next, Next, Next, Finish. Взгляд даже близко не зацепился за маленький желтый кружок с восклицательным знаком внизу окна одного из шагов мастера.
По окончании мастера свежий Datastore появился в списке… а вместе с ним и Datastores с остальных физических дисков.
Перехожу к навигации по только что добавленному Datastore, а он… пуст. Разумеется, я вновь впал в изумление. 8 утра на часах, первые 15 минут на работе после отпуска, даже сахар в кофе еще не размешал. И тут такое. Первая мысль была — не тот диск из «родного» хоста вытянул. Посмотрел, присутствует ли искомый Datastore в «родном» хосте: нет, не присутствует. Вторая мысль была: «бля#ь!». Не уверен, но мне кажется, что третья, четвертая и как минимум пятая мысль была такая же.
Чтобы развеять сомнения, по-быстрому установил на пробу свежий ESXi, взял левый диск и, уже вчитываясь, прошелся по шагам мастера. Да. При добавлении Datastore с помощью мастера происходит потеря всех данных на диске без возможности отката операции и восстановления данных. Позже я прочитал на одном из форумов оценку такого дизайна мастера: shitsome crap. И прямо вот очень согласился.
Начиная с шестой — мысли потекли в более конструктивном русле. Ладно. Инициализация занимает считанные секунды даже для 3Tb-диска. Значит, это высокоуровневое форматирование. Значит, просто была переписана таблица разделов. Значит, данные все еще там. Значит, сейчас поищем какой-нибудь unformat и voila.
Гружу машину с загрузочного образа Strelec… И выясняю, что программы восстановления разделов знают все, кроме VMFS. Разметку разделов Synology, например, знают, а вот VMFS — нет.
Перебор программ не утешителен: в лучшем случае GetDataBack и R.Saver находят NTFS-разделы с живой структурой каталогов и живыми именами файлов. Но меня это не устраивает. Мне нужны два vmdk-файла: с диском системы и диском файлов помойки.
И тут я понимаю, что, похоже, сейчас буду ставить винду и раскатываться из файлового бэкапа. И одновременно с этим вспоминаю, что у меня там был корень DFS. А еще совершенно дикая по объему и разветвленности система прав доступа к папкам подразделений. Не вариант. Единственный приемлемый по времени вариант — восстановление состояния системы и диска с данными и всеми правами.
Снова гуглинг, форумы, KB’шки и снова плач Ярославны: VMware ESXi не предусматривает механизма восстановления данных. Все ветки обсуждений имеют два финала: кто-то восстановился с помощью не дешевой DiskInternals VMFS Recovery или кому-то помог активно продвигающий свои услуги специалист по vmfs-tools и dd. Вариант с покупкой лицензии DiskInternals VMFS Recovery за $700 — не вариант. Допуск постороннего лица с «территории потенциального противника» к корпоративным данным — тоже не вариант. Зато было нагуглено, что VMFS разделы умеет читать так же еще UFS Explorer.
DiskInternals VMFS Recovery
Была скачана и установлена триальная версия. Программа успешно увидела пустой VMFS раздел:
В режиме Undelete (Fast Scan) так же нашла и потертый Datastore c папками виртуальных машин с дисками внутри:
Предпросмотр показал, что файлы живые:
Монтирование раздела в систему было успешным, но по непонятной причине во всех трех папках была одна и та же виртуалка. Конечно, по закону подлости — не та, что требуется.
Предпринятая попытка бессовестно запиратить софтину закончилась провалом. Зато запиратился UFS Explorer.
UFS Explorer
Сканирование диска показало наличие 7 нод. Количество нод «удивительным образом» совпало с количеством *-flat.vmdk файлов, обнаруженных VMFS Recovery:
Сравнение размеров файлов и размеров нод показало так же совпадение до байта. Заодно были восстановлены имена *-flat.vmdk файлов и, соответственно, принадлежность их к виртуальным машинам.
Вообще, vmdk-диски с точки зрения ESXi состоят из двух файлов: это файл с данными (<имя машины>-flat.vmdk) и файл «физической» разметки диска (<имя машины>.vmdk). Если с локальной машины в Datastore залить *-flat.vmdk файл, то ESXi его не распознает как валидный файл диска. В базе знаний VMware есть статья о том, как вручную создать файл дескриптора диска: kb.vmware.com/s/article/1002511, но мне делать этого не пришлось, я просто скопипастил содержимое соответствующих файлов из области предпросмотра содержимого файла в DiskInternals VMFS Recovery:
Спустя 4 часа выгрузки 2,5Тб нода из UFS Explorer’a и 20 часов загрузки в Datastore гипервизора грохнутые файлы дисков были подключены к свеже-созданной виртуальной машине. Диски подхватились. Потери данных замечено не было.
Flat vmdk что это
Немного справочной информации. В VMware есть несколько основных файлов виртуальной машины:
- *-flat.vmdk — бинарный файл данных. Размер равен размеру HDD;
- *.vmdk — файл конфигурации жёсткого диска;
- *.vmx — Файл конфигурации машины.
Что делать, если при запуске виртуальной машины Вы столкнулись с ситуацией, когда она как бы потеряла свой жесткий диск?
Описание форматов файлов виртуальной машины ESXI
Описание форматов файлов виртуальной машины ESXI
Всем привет! Сегодня расскажу про форматы файлов виртуальной машины Vmware ESXI. Если вы откроете диск на, котором лежит ваша виртуальная машина, то вы найдете там набор файлов, понимание того, что за что отвечает даст вам понимание того, как потом ремонтировать вашу VM. Данный знания вам окажутся полезным, при модификации конфигурационного файла или же при конвертировании в OVF формат, либо же избавление от SWAP файла (Файла подкачки). Думаю, что это будет интересно.
Структура файлов в ESXI виртуальной машине
Откроем ваш datastore с нужной виртуальной машиной через правый клик и выбор пункта меню Browse.
Переходим в папку с вашей виртуальной машиной (VM) и видим некоторый набор файлов.
Описание форматов файлов виртуальной машины ESXI
Хочу отметить, что flat вы через vCenter сервер не увидите, так сделано.
для этого придется вам включить ssh и подключиться либо через WinSCP или же, через ssh клиента. И вот там вы уже их обнаружите.
Роль диска ВМ выполняет пара файлов – .vmdk и -flat.vmdk.
Именно в последнем содержаться те данные, что лежат на диске виртуалки.
Притом, этот файл по умолчанию создается предразмеченным – т.е. под него резервируется все место, которое он может занять. Т.о., если вы создали диск для ВМ и его размер указали в 40 ГБ, все 40 ГБ на VMFS разделе у окажутся занятыми сразу.
(Отступление в сторону – если vmdk создается на NFS разделе, то именно на NFS он сразу создается в формате "thick" – "растущий" по факту, с нулевым начальным размером. Так же, можем в этом формате создавать vmdk и на VMFS – но сейчас только с помощью командной строки, не из GUI. Подробнее тут – Типы дисков(vmdk файлов))
Так вот. Теперь, с ВМ мы можем сделать снапшот. Это – снимок состояния, фиксация текущего состояния этой ВМ, на которое можно вернуться потом.
Технически это означает следующее:
файл -flat.vmdk переводится в режим только чтения.
Создается файл –delta0001.vmdk, и в эту дельту начинают писаться те блоки, которые меняются относительно исходного файла. Т.е. по умолчанию дельта размера 0, а потом начинает расти. Растет она блоками по 16 МБ. Это не очень хорошо, потому что для каждого увеличения генериться SCSI reservation. Один SCSI reservation – это нормально, но если они будут генериться часто – это приведет к снижению производительности дисковой подсистемы.
Если спустя еще какое то время сделать еще один снапшот, то теперь в режим только чтение переводится и -delta0001.vmdk, и появляется файл -delta0002.vmdk. Во вторую дельту начинают писаться те блоки, которые меняются относительно -flat.vmdk+ -delta001.vmdk.
Файл -delta000 Xvmdk не будет размером больше, чем номинальный размер диска ВМ.
В моем примере это 40 ГБ.
ВАЖНО!
Для функционирования ВМ нужны все vmdk файлы – и основной, -flat.vmdk, и все файлы-дельта. Не уподобляйтесь персонажу отсюда.
На что стоит обратить внимание:
ВМ с диском в 40 ГБ реально на VMFS разделе может занимать до 40*(кол-во снапшотов + 1) гигабайт места. Каждая такая ВМ.
Притом, есть мнение, что в некоторых случаях файлы дельты могут расти достаточно активно при практически нулевой активности с диском ВМ. Ведь даже тогда, когда вы или приложение ничего не меняете на диске виртуалки, там есть файл подкачки, к примеру – который меняется => растет дельта.
Так же крайне не рекомендуется делать дефрагментацию ВМ со снапшотами – ибо вырастет дельта, и вырасти она может сильно.
Удаление снапшота размером в 100ГБ может занимать 3-6 часов.
Расширять диск ВМ имеющей снапшоты – плохая идея. Увеличить размер диска можно командой vmkfstools -X или из GUI(начиная с 3.5 версии ESX). Так вот, скорее всего, ВМ больше не стартует, если расширение диска было произведено при имеющихся снапшотах. Как чинить – Top Support Issues and How to Solve Them – Batch 2.
Если есть желание, чтобы диск ВМ был неподвержен снапшотам, то в его свойствах выберите " Independent ". Кстати, если ВМ имеет " Independent " диски, то в снапшот не может быть включена ее память.
Flat vmdk что это
Всем привет! Сегодня расскажу про форматы файлов виртуальной машины Vmware ESXI. Если вы откроете диск на, котором лежит ваша виртуальная машина, то вы найдете там набор файлов, понимание того, что за что отвечает даст вам понимание того, как потом ремонтировать вашу VM. Данный знания вам окажутся полезным, при модификации конфигурационного файла или же при конвертировании в OVF формат, либо же избавление от SWAP файла (Файла подкачки). Думаю, что это будет интересно.
Структура файлов в ESXI виртуальной машине
Откроем ваш datastore с нужной виртуальной машиной через правый клик и выбор пункта меню Browse.
Переходим в папку с вашей виртуальной машиной (VM) и видим некоторый набор файлов.
Описание форматов файлов виртуальной машины ESXI
Хочу отметить, что flat вы через vCenter сервер не увидите, так сделано.
для этого придется вам включить ssh и подключиться либо через WinSCP или же, через ssh клиента. И вот там вы уже их обнаружите.
Понимание файлов виртуальной машины VMware
Эффективно перемещайтесь по каждому из типов файлов виртуальных машин VMware, таких как файл flat.vmdk и файл VSWP, чтобы упростить задачи управления виртуальными машинами.
Понимание файлов виртуальных машин VMware может облегчить задачи управления и упростить очистку инфраструктуры.
Зная виртуальные машины с аппаратной точки зрения, вы можете изучить компоненты, из которых состоит виртуальная машина на хосте ESX/ESXi. Вы можете найти различные типы файлов VMware VM в каталоге VM на хосте. Тремя основными типами являются файлы NVRAM, файлы VMX и файлы VMDK.
Файлы виртуальных машин VMware организованы в файловой системе виртуальных машин (VMFS) . Если вы посмотрите на список файлов, связанных с виртуальной машиной, — используйте инструмент на основе протокола безопасного копирования (SCP) или следуйте рекомендациям VMware — вы заметите, что большинство файлов начинаются с фактического имени виртуальной машины, за которым следуют другие имена. расширения файлов, обозначающие тип файла. Вы можете не увидеть все возможные типы файлов в VMFS, пока ваша виртуальная машина не достигнет определенного состояния. Например, вы видите файл VSWP только при включении виртуальной машины. Точно так же вы найдете файл VMSS только тогда, когда приостановите свою виртуальную машину. Вы можете использовать WinSCP для просмотра списка каталогов ваших виртуальных машин.
Из чего состоят файлы виртуальной машины VMware?
Файл NVRAM . Этот небольшой файл содержит BIOS (базовую систему ввода-вывода), которую виртуальная машина использует для загрузки. Это похоже на физический сервер с чипом BIOS , который позволяет вам устанавливать параметры конфигурации оборудования. Виртуальная машина также имеет виртуальный BIOS, содержащийся в файле NVRAM. Вы можете получить доступ к BIOS при первом запуске виртуальной машины, нажав клавишу F2. Все изменения, которые вы вносите в аппаратную конфигурацию виртуальной машины, сохраняются в файле NVRAM. Этот файл имеет двоичный формат, и если он удален, виртуальная машина автоматически воссоздает его при повторном включении.
Файл VMX . Этот файл содержит всю информацию о конфигурации и аппаратных настройках виртуальной машины. Всякий раз, когда вы редактируете настройки виртуальной машины, этот файл сохраняет всю эту информацию в текстовом формате. Этот файл содержит разнообразную информацию о виртуальной машине, в том числе ее конкретную аппаратную конфигурацию, т. е. размер ОЗУ, информацию о карте сетевого интерфейса, информацию о жестком диске и информацию о последовательном/параллельном порте, расширенные настройки питания и ресурсов, параметры инструментов VMware и варианты управления питанием. Хотя вы можете редактировать этот файл напрямую, чтобы внести изменения в конфигурацию виртуальной машины, не делайте этого, если вы не уверены, что знаете, что делаете. Если вы вносите изменения непосредственно в этот файл, сначала сделайте его резервную копию.
VMDK-файлы . Все виртуальные диски состоят из двух файлов: большого файла данных, равного размеру виртуального диска, и небольшого текстового файла дескриптора диска, который описывает размер и геометрию виртуального диска. Файл дескриптора также содержит указатель на большой файл данных, а также информацию о секторах, головках, цилиндрах и типе дискового адаптера виртуального диска. В большинстве случаев эти файлы имеют то же имя, что и связанный с ними файл данных, т. е. myvm_1.vmdk и myvm_1-flat.vmdk. Вы можете сопоставить файл дескриптора с файлом данных, проверив поле «Описание экстента» в этом файле, чтобы увидеть, какой плоский файл, RDM (необработанное сопоставление устройств) или дельта-файл связаны с ним.
Другие типы файлов VMDK
Различные типы файлов VMDK , которые можно использовать с виртуальными машинами VMware, включают следующие:
Файл flat.vmdk. Система создает этот большой файл данных виртуального диска по умолчанию, когда вы добавляете к виртуальной машине виртуальный жесткий диск, который не является файлом RDM. При использовании толстых дисков размер этого файла примерно равен тому, который вы указали при создании виртуального жесткого диска. Каждый виртуальный жесткий диск, настроенный виртуальной машиной, должен иметь один из этих файлов.
Файл delta.vmdk. Вы используете эти файлы VMDK только при создании снимков. . Когда вы создаете моментальный снимок, он останавливает все записи в исходный файл flat.vmdk, и файл становится доступным только для чтения; вместо этого система записывает изменения на виртуальный диск в эти дельта-файлы. Начальный размер этих файлов составляет 16 МБ, и они увеличиваются по мере необходимости с шагом 16 МБ по мере внесения изменений на виртуальный жесткий диск виртуальной машины. Поскольку эти файлы представляют собой растровое изображение изменений, внесенных в виртуальный диск, размер одного файла delta.vmdk не может превышать размер исходного файла flat.vmdk. Система создает дельта-файл для каждого моментального снимка, который вы создаете для виртуальной машины. Их имена файлов увеличиваются численно, например, myvm-000001-delta.vmdk, myvm-000002-delta.vmdk и т. д. Когда вы удаляете снимок, система автоматически удаляет эти файлы после того, как вы объедините их обратно в исходный flat.vmdk. файл.
Файл rdm.vmdk. Это файл сопоставления для формата RDM, который управляет данными сопоставления для устройства RDM. Файл сопоставления представляется хосту ESX как обычный файл на диске, доступный для обычных операций с файловой системой. Однако для виртуальной машины уровень виртуализации хранилища представляет сопоставленное устройство как виртуальное устройство SCSI . Метаданные в файле сопоставления включают местоположение сопоставленного устройства, т. е. разрешение имени, и состояние блокировки сопоставленного устройства. Если вы сделаете список каталогов, вы увидите, что эти файлы занимают столько же места на диске тома VMFS, сколько фактический размер номера логического устройства, с которым они сопоставлены, но на самом деле они небольшие. Система создает один из этих файлов для каждого RDM, который вы создаете на виртуальной машине.
Файл VSWP . Когда вы включаете виртуальную машину, система создает файл подкачки памяти. Вы можете использовать это вместо физической памяти хоста, если хост ESX исчерпывает всю свою физическую память из-за чрезмерного выделения. Система создает эти файлы, равные по размеру объему памяти, назначенной виртуальной машине, за вычетом любых резервирований памяти (по умолчанию 0), которые могли быть установлены для нее виртуальной машиной. Файл VSWP размером 3 ГБ. Виртуальная машина всегда имеет эти файлы, но использует их только в том случае, если хост исчерпал всю свою физическую память. Поскольку чтение/запись памяти виртуальной машины на диск выполняется медленнее, чем физическая оперативная память хоста, производительность вашей виртуальной машины снижается, если она использует этот файл. Эти файлы могут занимать довольно много дискового пространства на томах VMFS, поэтому убедитесь, что у вас достаточно места для них, поскольку виртуальная машина не включится, если у нее недостаточно места для создания этого файла.
Виртуальные машины блокируют файлы VSWP, flat.vmdk, delta.vmdk, VMX и LOG во время выполнения.
Файл VMSS . Этот файл сохраняет содержимое памяти виртуальной машины, чтобы она могла снова запуститься с того места, где остановилась, когда вы приостанавливаете виртуальную машину. Этот файл занимает примерно столько же места, сколько объем оперативной памяти, назначенной виртуальной машине, включая пустое содержимое памяти. Когда вы выводите виртуальную машину из приостановленного состояния, система записывает содержимое этого файла обратно в физическую память хост-сервера. Однако файл не удаляется автоматически, пока вы не выключите виртуальную машину — перезагрузка ОС не сработает. Если предыдущий файл приостановки существует, когда вы снова приостанавливаете виртуальную машину, система повторно использует этот файл вместо его удаления и повторного создания. Если вы удалите этот файл, когда виртуальная машина приостановлена, то виртуальная машина запустится в обычном режиме, а не из приостановленного состояния.
VMSD-файл . Система использует этот файл для хранения метаданных и другой информации о каждом активном моментальном снимке виртуальной машины. Этот текстовый файл начинается с размера 0 байт, пока вы не создадите снимок. Файл VMSD обновляется информацией каждый раз, когда вы создаете или удаляете моментальные снимки. Только один из этих файлов существует независимо от количества запущенных моментальных снимков, поскольку все они обновляют этот единственный файл. Информация о моментальном снимке в файле VMSD состоит из имени файла VMDK и файла VMSD, которые использует каждый моментальный снимок, отображаемого имени и описания, а также уникального идентификатора (UID) моментального снимка. После удаления всех снимков в этом файле сохраняется информация о старых снимках, но увеличивается UID снимка для использования с новыми снимками. Он также переименовывает первый снимок в Consolidate Helper, предположительно для использования с консолидированными резервными копиями.
Файл VMSN . Система использует этот файл для хранения состояния виртуальной машины, когда вы делаете снимок. Система создает отдельный файл VMSN для каждого моментального снимка виртуальной машины и автоматически удаляет его при удалении моментального снимка. Размер этого файла зависит от того, хотите ли вы включить состояние памяти виртуальной машины в свой снимок. Если вы выберете сохранение состояния памяти, этот файл будет немного больше, чем объем ОЗУ, назначенный виртуальной машине, так как система копирует все содержимое памяти, включая пустую память, в этот файл. Если вы решите не сохранять состояние памяти моментального снимка, этот файл будет довольно маленьким — менее 32 КБ. Этот файл похож на VMSS, который вы используете при приостановке работы виртуальных машин.
Файл журнала . Система создает этот файл для регистрации информации о виртуальной машине, и он часто используется для устранения неполадок. В каталоге виртуальной машины есть несколько таких файлов. Текущий файл журнала всегда называется vmware.log. В системе сохраняется до шести старых файлов LOG с числом в конце их имен, т. е. vmware-2.log. Система создает новый файл журнала либо при выключении и повторном включении виртуальной машины, либо при достижении максимального размера файла журнала. Количество файлов LOG, которые система сохраняет, и максимальный размер определяются как параметры расширенной конфигурации виртуальной машины: log.rotateSize и log.keepOld .
Файл VMXF . Этот файл является дополнительным файлом конфигурации, сохраненным для совместимости с VMware Workstation . Он представлен в текстовом формате, и Workstation использует его для объединения виртуальных машин, где он может назначать несколько виртуальных машин команде, чтобы вы могли включать или выключать их, приостанавливать и возобновлять их работу как единый объект.
CTK-файл. В файлах VMware CTK перечислены все изменения, внесенные в виртуальную машину между резервными копиями. Этот файл описывает блок VMDK и увеличивается пропорционально количеству блоков VMDK. На каждый VMDK приходится один файл CTK. Файлы отслеживания изменений созданы с помощью технологии отслеживания измененных блоков VMware для добавочного резервного копирования. В файле CTK хранится информация о том, какие информационные блоки ВМ изменились, что позволяет избежать ненужных резервных копий блоков. Снимки VMware также используют файлы CTK. Как и файлы LOG и NVRAM, файлы CTK имеют небольшой размер.
Другие менее частые файлы виртуальных машин VMware включают файл подкачки виртуальной машины VMEM и файл конфигурации VMTM для данных группы. Как и файлы VMSN, файлы VMEM создают резервную копию памяти виртуальной машины. Они существуют, когда вы запускаете виртуальную машину или в случае сбоя виртуальной машины. Файлы VMEM поддерживают группы виртуальных машин — функцию в VMware Workstation, которая позволяет группе виртуальных машин работать вместе через частный сегмент локальной сети.
Проверьте виртуальные машины на собственных хостах VMware, чтобы увидеть различные файлы, из которых состоят эти виртуальные машины. Вы можете найти старые данные на томах VMFS. Прежде чем удалять какие-либо файлы, убедитесь, что удаляемые файлы вам больше не нужны и что виртуальная машина их не использует.