Устройство 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-раздела.

Запись опубликована в рубрике VMware, vSphere с метками . Добавьте в закладки постоянную ссылку.

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

  1. леонид говорит:

    а как быть если для vmhba2:0:0:0 нарушилась геометрия?

  2. A.Vakhitov говорит:

    Добрый вечер. Не понял вопроса.

  3. Evgeny говорит:

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

  4. A.Vakhitov говорит:

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

  5. vmarkovsky говорит:

    Помогите побороть ошибку. 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 |…………….|
    *
    В чем может быть причина?

  6. vmarkovsky говорит:

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

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

  7. Pavel говорит:

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

  8. Андрей Вахитов говорит:

    Какая версия ESX/ESXi?

  9. Pavel говорит:

    Версия ESX 4.0.0

  10. A.Vakhitov говорит:

    завтра постараюсь проверить

  11. Pavel говорит:

    Жаль, что не удалось проверить 🙁

  12. Sergey говорит:

    А как можно побороть такую проблему: после неясного глюка часть вируальных машин перешла в состояние 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. Возможно глюк на дисковой полке вызвал это.

  13. A.Vakhitov говорит:

    Хост пробовал перезагружать? Возможно, виртуалки просто «зависли»?

  14. Sergey говорит:

    Да, конечно перегружал.

  15. Андрей Вахитов говорит:

    Раздел собирал из 2ТБ или (2ТБ-512байт)?

    Попробуйте этот рецепт (http://conshell.net/wiki/index.php/Recovery_of_Locked_VMDK)

  16. Sergey говорит:

    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

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

  17. Андрей Вахитов говорит:

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

  18. Sergey говорит:

    Так прличное время все работало без проблем.
    Написал уже. Пока тишина.
    http://communities.vmware.com/thread/268366?tstart=0

  19. Vovka говорит:

    коллеги, а как можно восстановить удлённые файлы с vmfs раздела?

  20. Андрей Вахитов говорит:

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

  21. Vovka говорит:

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

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

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

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

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

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

  22. Андрей Вахитов говорит:

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

  23. Андрей Вахитов говорит:

    Буду ждать новостей.
    Успехов!

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

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