Устройство 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:

vhhba#:Target:LUN:Partition -> vml:??_LUN_??_GUID:Partition
                       LUN     GUID                         PARTITION
                       ^       ^                            ^
vmhba0:1:0:0  -> vml.02000000005005076719d163d844544e313436
vmhba0:1:0:1  -> vml.02000000005005076719d163d844544e313436:1
vmhba32:1:3:0 -> vml.0200030000600144f07ed404000000496ff8cd0003434f4d535441
vmhba32:1:3:1 -> vml.0200030000600144f07ed404000000496ff8cd0003434f4d535441:1
Если же выполнить команду ls -l в каталоге /vmfs/volumes, то мы узнаем имя и UUID VMFS-разделов.

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, но это не совсем он.

[root@vh1 root]# hexdump -C -s 0x100000 -n 800 /dev/sdf1
00100000  0d d0 01 c0 03 00 00 00  10 00 00 00 02 16 03 00  |................| <- LUN ID
00100010  00 06 53 55 4e 20 20 20 20 20 43 4f 4d 53 54 41  |..SUN     COMSTA| <- Target Label
00100020  52 20 20 20 20 20 20 20 20 20 31 2e 30 20 60 01  |R         1.0 `.| <- LUN GUID
00100030  44 f0 7e d4 04 00 00 00 49 6f f8 cd 00 03 43 4f  |D.~.....Io....CO|
00100040  4d 53 54 41 00 00 00 00  00 00 00 00 00 00 00 00  |MSTA............|
00100050  00 00 00 00 00 00 00 00  00 00 00 02 00 00 00 fc  |................| <- Volume Size
00100060  e9 ff 18 00 00 00 01 00  00 00 8f 01 00 00 8e 01  |................|
00100070  00 00 91 01 00 00 00 00  00 00 00 00 10 01 00 00  |................|
00100080  00 00 d8 6c 71 49 b0 aa  97 9b 6c 2f 00 0d 60 d4  |...lqI....l/..`.|
00100090  6e 2e 6e 89 19 fb a6 60  04 00 a7 ce 20 fb a6 60  |n.n....`.... ..`|
001000a0  04 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
001000b0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00100200  00 00 00 f0 18 00 00 00  90 01 00 00 00 00 00 00  |................|
00100210  01 00 00 00 34 39 37 31 36 63 64 38 2d 36 30 37  |....49716cd8-607| <- SEG UUID in ASCII
00100220  35 38 39 39 61 2d 61 64 31 63 2d 30 30 30 64 36  |5899a-ad1c-000d6|
00100230  30 64 34 36 65 32 65 00  00 00 00 00 00 00 00 00  |0d46e2e.........|
00100240  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00100250  00 00 00 00 d8 6c 71 49 9a 89 75 60 1c ad 00 0d  |.....lqI..u`....| <- SEG UUID
00100260  60 d4 6e 2e 01 00 00 00  e1 9c 19 fb a6 60 04 00  |`.n..........`..|
00100270  00 00 00 00 8f 01 00 00  00 00 00 00 00 00 00 00  |................|
00100280  8e 01 00 00 00 00 00 00  64 cc 20 fb a6 60 04 00  |........d. ..`..|
00100290  01 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
001002a0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

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

[root@vh1 ]# hexdump -C -s 0x200000 -n 256 /vmfs/volumes/49716cd8-ebcbbf9a-6792-000d60d46e2e/.vh.sf
00200000  5e f1 ab 2f 04 00 00 00  1f d8 6c 71 49 9a bf cb  |^../......lqI...| <- VMFS UUID
00200010  eb 92 67 00 0d 60 d4 6e 2e 02 00 00 00 73 73 32  |..g..`.n.....ss2| <- Volume Name
00200020  2d 63 73 74 61 72 2d 7a 73 30 2e 32 00 00 00 00  |-cstar-zs0.2....|
00200030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00200090  00 00 00 00 00 00 00 00  00 00 00 00 00 00 02 00  |................|
002000a0  00 00 00 10 00 00 00 00  00 d8 6c 71 49 01 00 00  |..........lqI...|
002000b0  00 d8 6c 71 49 9a 89 75 60 1c ad 00 0d 60 d4 6e  |..lqI..u`....`.n| <- SEG UUID
002000c0  2e 01 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
002000d0  00 00 00 01 00 20 00 00  00 00 00 01 00 00 00 00  |..... ..........|
002000e0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

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

hexdump -C -n 256 /dev/sdf1
00000000  fa b8 00 10 8e d0 bc 00  b0 b8 00 00 8e d8 8e c0  |................|
00000010  fb be 00 7c bf 00 06 b9  00 02 f3 a4 ea 21 06 00  |...|.........!..|
00000020  00 be be 07 38 04 75 0b  83 c6 10 81 fe fe 07 75  |....8.u........u|
00000030  f3 eb 16 b4 02 b0 01 bb  00 7c b2 80 8a 74 01 8b  |.........|...t..|
00000040  4c 02 cd 13 ea 00 7c 00  00 eb fe 00 00 00 00 00  |L.....|.........|
00000050  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000001b0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 02  |................|
000001c0  03 00 fb fe ff ff 80 00  00 00 72 ef bf 5d 00 00  |..........r..]..| Type Start End
000001d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

Теперь мы готовы исправлять такие проблемы как случайное удаление раздела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-раздела: 25 комментариев

  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.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *