Устройство VMFS-раздела

Собрался с силами и перевел статью Mike Laspina.

Понимание архитектуры VMFS очень важно для правильного обслуживания инфраструктуры Vmware. Когда журнал хранилища пестрит ошибками, необходимо точно оценить состояние VMFS-раздела и провести необходимые работы по исправлению ошибок. Так как описание архитектуры VMFS отсутствует в публичном доступе, займемся анализом 😉

У VMFS-раздела идентификатор тома равен fb. Давайте выполним команду fdisk и убедимся в этом:

[root@vh1 ]# fdisk -lu /dev/sdc

Disk /dev/sdc: 274.8 GB, 274877889536 bytes
255 heads, 63 sectors/track, 33418 cylinders, total 536870878 sectors
Units = sectors of 1 * 512 = 512 bytes

Device Boot Start End Blocks Id System
/dev/sdc1 128 536860169 268430021 fb Unknown
Запомним также размер блока — 512 байт, а также начало и конец раздела.

Некоторые настройки можно увидеть в каталоге /mount. Он содержит два подкаталога: устройств(devices) и разделов(volumes). Каталог разделов содержит точки монтирования, каталог устройств — настройки устройств. Каталог устройств также содержит несколько подкаталогов, из них я знаю содержание подкаталогов disks и lvm.

Ключевым параметром VMFS-раздела является UUID, он же используется в качестве имени раздела при наличии нескольких разделов, чтобы избежать конфликтов. UUID создается при создании VMFS-раздела. По UUID можно определить, какой хост создал этот раздел — последние шесть байт совпадают с последними шестью байтами UUID ESX (/etc/vmware/esx.conf).

Вторым ключевым параметром является GUID, который необходим для доступа к разделу при использовании нескольких путей (Virtual Multipath Link или vml). GUID хранится в заголовке раздела VMFS и начинается с адреса  0x10002E. Формат GUID зависит от используемой версии SCSI, есть различия в длине этого параметра, в зависимости от формата адресов SCSI, например, EUI-64 или NAA 64. Обратим внимание на компоненты vml, не относящиеся к GUID — vml содержит ссылку на LUN и раздел. Давайте запустим в каталоге /vmfs/devices/disks команду ls -l:

ss2-cstar-zs0.2 -> 49716cd8-ebcbbf9a-6792-000d60d46e2e

Также мы можем увидеть UUID с помощью команды esxcfg-vmhbadevs -m:

[root@vh1 ]# esxcfg-vmhbadevs -m
vmhba0:1:0:1 /dev/sdd1 48a3b0f3-736b896e-af8f-00025567144e
vmhba32:1:3:1 /dev/sdf1 49716cd8-ebcbbf9a-6792-000d60d46e2e

Как мы видим, длина GUID действительно различается, а vmhba использует vml для того, чтобы ядро корректно «увидело» необходимый LUN и раздел.

Вся информация об vml хранится в заголовке раздела VMFS. Там же находится нечто, напоминающее UUID, но это не совсем он.

Кроме заголовка, у нас есть еще и скрытые метаданные, которые мы можем рассекретить с помощью команды ls -al. Файл vh.sf содержит UUID нашего раздела, а также информацию о секторах.

Поищем информацию о секторах и типе раздела:

Теперь мы готовы исправлять такие проблемы как случайное удаление разделаVMFS или смена его идентификатора.

В Esx 3.5 Update 3 появилась утилита vmfs-undelete, которая экспортирует метаданные в журнал, из которого можно восстановить информацию поблочно в случае удаления. Это простая утилита, она сейчас не поддерживается официально и недоступна на ESXi. Тем не менее, данная утилита полезна, если вы создавали резервные копии с ее помощью. Если же нет, то нам придется воспользоваться другими средствами.

Удаление раздела достаточно легко поправить, так как фактически удаления заголовка VMFS не происходит! Информация с раздела считается мусором, но удаляется только при записи новой информации. В общем-то нам необходимо восстановить кусок из первых 128 байт раздела. Один из методов — создание нового раздела с тем же именем, поблочное копирование его в файл, который можно будет использовать для лечения удаленного раздела.

Например, мы создаем новый VMFS-раздел на том же хранилище с таким же размером. Команда esxcfg-vmhbadevs -m показывает, что это /dev/sdd, тогда как удаленный раздел был /dev/sdc.

Используем команду dd для поблочного копирования (и не забудьте сделать резервную копию данных).

dd if=/dev/sdc of=/var/log/part-backup-sdc-1st.hex bs=512 count=1

а затем

dd if=/dev/sdd of=/dev/sdc bs=512 count=1

Или можно сделать так:

dd if=/dev/sdd of=/var/log/part-backup-sdd.hex bs=512 count=1
dd if=/var/log/part-backup-sdd.hex of=/dev/sdc bs=512 count=1
Лично я предпочитаю использовать файл, так как это более безопасно, у нас есть резервная копия, да и файл легко можно отредактировать любым шестнадцатиричным редактором. Кроме того, можно использовать fdisk и вручную прописать в таблицу раздела правильные значения начального и конечного секторов. Но это стоит делать, если вы точно знаете, что делаете 😉

Мы можем дополнительно скопировать наш заголовок VMFS и файл vh.sf

cp /vmfs/volumes/49716cd8-ebcbbf9a-6792-000d60d46e2e/.vh.sf /var/log/vh.sf.bu
dd if=/dev/sdc of=/var/log/vmfsheader-bu-sdc.hex bs=512 count=4096
Это даст нам точную информацию о разделе VMFS и сможет помочь и в более сложных случаях.

Еще один распространенный случай — когда случайно меняется LUN, содержащий VMFS. Если сменится идентификатор LUN и LUN подключен к серверу ESX, то система предположит, что это LUN для снимков. В этом случае настройки LVM не дадут подмонтировать раздел!

Если вы подозреваете, что проблема в том, что LUN ID сменился, наилучшее решение — это сменить его обратно и пересканировать VMHBAs. Если же вы смените UUID VMFS-раздела, вам также придется импортировать обратно все виртуальные машины и корректировать множество других настроек Virtual Center.

Если изменение настроек хранилища не помогло, то придется сменить UUID раздела. Для этого зададим параметры хоста —  LVM.DisallowSnapshotLun = 0 and LVM.EnableResignature = 1. Как только операция по смене UUID пройдет успешно, параметры необходимо сменить обратно.

——————————

1) Оригинал статьи;

2)  Duncan Epping радует гайдом по защите данных с раздела VMFS;

3) Leo Raikhman публикует скрипт для планировщика заданий, позволяющий в автоматизированном режиме резервировать заголовок VMFS-раздела.

Устройство VMFS-раздела: 29 комментариев

  1. На ESXi 3.5 U4 djpybrkf ошибка бут сектора. После зауска установки с дистрибутива выбрал repaire установка прошла успешно, но inventory пуст, есть ли решения данной проблемы? как вытянуть образы машин из слитого посекторно хранилища?

  2. Подозреваю, что вам необходимо сначала восстановить хранилище из посекторной копии.
    Вроде бы подобная команда…
    dd if=/var/log/part-backup-sdd.hex of=/dev/sdc bs=512 count=1

  3. Помогите побороть ошибку. LUN видно, Datastore — нет. Пробовал http://blog.vadmin.ru/2008/11/vmfs.html — не помогло. (раздел был виден изначально). Что удивительно, вывод hexdump -C -s 0x100000 -n 800 /dev/ для живого диска — как у Вас выше, а вывод для проблемного диска — только до адреса 00100050, и сами данные — совсем не похожи на стандартные:
    00100000 00 81 00 00 00 81 01 00 00 81 02 00 00 81 03 00 |…………….|
    00100010 00 81 04 00 00 81 0c 00 00 81 0d 00 00 81 18 00 |…………….|
    00100020 00 81 28 00 00 81 3e 00 00 81 79 00 00 81 ab 00 |..(…>…y…..|
    00100030 00 81 38 01 00 81 6c 01 00 81 45 04 00 81 b0 04 |..8…l…E…..|
    00100040 00 81 1a 06 00 81 d0 0c 00 00 00 00 00 00 00 00 |…………….|
    00100050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |…………….|
    *
    В чем может быть причина?

  4. vmkfstools-L targetreset уже пробовал — безрезультатно.
    Не понятно, как fdisk что-то находит, если hexdump выдает такой мусор, еще и не весь сектор показывает.

    Можно-ли вытянуть из этого раздела VMDK файл?

  5. Добрый день!
    Я увеличил объем iSCSI-тома на стороне хранилища, теперь пытаюсь увеличить Datastor на стороне ESX-сервера. Сервер по-прежнему показывает Capacity старого размера. Как сделать расширить Datastor на весь объем тома?
    Спасибо!

  6. А как можно побороть такую проблему: после неясного глюка часть вируальных машин перешла в состояние Invalid, часть нормально. Файлы невалидных виртуалок не дает открывать или копировать в консоле:
    [root@indium sbin]# cd /vmfs/volumes/YottaB-1/mars/
    [root@indium mars]# cat mars.vmx
    cat: mars.vmx: Invalid argument
    [root@indium mars]# cp mars.vmx test
    cp: cannot open `mars.vmx’ for reading: Invalid argument

    тоже с файлом данных. Унес «живые» виртуалки на другой стораж, гуглю на тему что теперь делать.
    ESX 4U1 и FC дисковая полка. VMFS собран из 4-х 2Тб слайсов.
    Подозрение на проблему VMFS. Возможно глюк на дисковой полке вызвал это.

  7. 2Тб. 2000Gb как указано в GUI дисковой полки

    По поводу ссылки. Получил ту же ошибку открытия файла:
    [root@indium krypton]# time /usr/sbin/vcbExport -M 1 -F 1 -d krypton.vmdk -s ../krypton.old/krypton.vmdk
    [2010-05-15 11:13:47.805 F4EE1B60 info ‘App’] Current working directory: /vmfs/volumes/49eca93a-f4a67c9a-50e2-000423e62eb0/krypton
    [2010-05-15 11:13:47.976 F4EE1B60 error ‘vcbExport’] Error: Failed to open the disk: Invalid argument

    real 0m1.689s
    user 0m0.160s
    sys 0m0.080s

    Т.е. надо как-то чекать файловую систему на полке

  8. Возможно, косяк случился из-за размера. C другой стороны, обычно косяк с VMFS случается, когда происходит ее увеличение. Вы же использовали Extent (если я правильно понял).
    Попробуйте на английском VMware Community написать.

  9. 1) Из резервной копии;
    2) В ESX3,5U3 появился скрипт VMFS-undelete, но он требует некоторых действий перед тем, как начать восстановление. Насколько я понял, без этих действий данные он не восстановит.

  10. привет! спасибо за ответ! но…

    1) данные потерялись именно из-за восстановления из backup(((
    (ниже опишу ситуацию)

    2) в ESX v4 u2 нет такой комманды((( и потом она требует созданных ранее таблиц раздела vmfs((( что в данном случае выглядит именно как «поздно пить боржоми, когда почки отвалились».

    так вот ситуация такая:
    в veeam создан бэкап ВМ, но только одного её диска (системного) остальные подключенные виртуальные HDD в бэкап не включены в виду большого объёма (2 по 250гиг). при восстановлении из бэкапа чтобы не плодить виртуалки и не делать потом лишних телодвижений решено было восстановить ВМ с тем же именем (что в принципе согласитесь логично — выключили требующую восстановления ВМ — восстановили из бэкапа — включили — ВМ вновь в строю) система предупреждает, что ВМ с таким именем существует и спрашивает перезаписывать ли её. здесь-то и кроется «подстава»((( если согласиться перезаписать, то veeam удаляет полностью папку ВМ со всем её содержимым и состанавливает на её место то, что есть в бекапе. соответственно системный диск есть (восстановлен) а остальные подключённые к ВМ HDD были успешно удалены при восстановлении.

    Вот такая вот ситуация, парадоксальная до слёз — «Потеря данных при восстановлении»

    Теперь ищу как восстановить удалённые с vmfs раздела vmdk файлы, но поиски пока к сожалению тщетны((( Один ли Ontrack предлагает решить проблему за нехилое бабло(((

  11. Я правильно понял, что у вас в папке с ВМ лежали два VMDK-файла, каждый по 250ГБ?
    Сочувствую.
    Как мне кажется, лучше обратиться в тех.поддержку VMware — это дешевле, чем покупать Ontrack.

  12. Всем доброго дня. Извиняюсь за много букв, но хочется сразу обрисовать картину максимально подробно и прошу помощи специалистов

    Админ «грохнул» диск VMFS командой:

    dd if=/dev/urandom of=$1 bs=512 count=34
    dd if=/dev/urandom of=$1 bs=512 count=34 seek=$((blockdev --getsz $1 — 34))

    После этого диском не пользовались, ничего не записывали и сразу отключили.
    На диске стояла VMFS и несколько виртуальных машин, в том числе Windows (NTFS) — самая важная для меня. Я носил диск трём компаниям по восстановлению данных. Везде развели руками. Приговор: При таком удалении диска VMFS восстановлению не подлежит, а поскольку NTFS лежал внутри VMFS то адресация у файлов сбита. И несмотря на то, что файловая структура находится — содержимое восстанавливаемых файлов всё будет битое из-за фрагментации. Максимум, что мне предложили это выгнать все RAW файлы без имён и локаций, но это прозвучало чудовищно. Я решил попробовать сам воспользоваться различными программами восстановления. Пятью если быть точнее. На текущий момент DMDE показала наилучший судя по всему результат. Несмотря на то, что она нашла NTFS раздел меньшего размера чем он был на диске (114gb вместо 150gb), она нашла их два с одинаковым размером в основных результатах, но с разным количеством файлов и соответствий и ещё 15 разделов в дополнительных результатах с уменьшающимся от раздела к разделу количеством соответствий. Я стал восстанавливать самые ценные данные с одного из найденных разделов имеющим бОльшее число соответствий с файловой структурой (при количестве файлов в разделе 164864 количество соответствий — 14319). Всё бы хорошо, но около 40-50% нужных файлов оказались битые. Архива вообще ни одного живого. Я решил на одной из папок проверить, что DMDE достанет из второго основного раздела-клона, который она нашла. Результат меня несколько удивил: из второго раздела процент восстановленных целиком файлов оказался больше. Правда суждение это пока только по одной папке с 50 файлами где ни один файл из первого раздела не открылся, из второго открылось 5. В общем с восстановлением очень муторно.

    Есть ли всё-таки возможность после затирания начала и конца диска восстановить структуру VMFS с тем, чтобы NTFS внутри неё занял «своё» место?

    Заранее благодарен за любую консультацию и готов предоставить дополнительную информацию и «отдаться» в правильные руки в том числе на договорных условиях

    1. Добрый день.
      К сожалению, других идей у меня нет.
      Вроде бы в телеграм-чате VMGURU кто-то обращался в техподдержку с просьбой восстановить данные, содержавшиеся в удаленном снапшоте.
      И там даже ему как-то помогли, но…
      увы…
      Что-то рекомендовать я не могу.
      Если как-то получится восстановить данные — пожалуйста, расскажите и нам.

      1. Что-то я не нашёл этот канал. Есть сайт http://www.vmgu.ru, но на нём никаких отсылок в телеграм я не вижу. Можете прислать имя группы, если не затруднит?

Добавить комментарий для Андрей Вахитов Отменить ответ

Ваш адрес email не будет опубликован.