Собрался с силами и перевел статью 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:
|
1 |
vhhba#:Target:LUN:Partition -> vml:??_LUN_??_GUID:Partition |
|
1 |
LUN GUID PARTITION |
|
1 |
^ ^ ^ |
|
1 |
vmhba0:1:0:0 -> vml.02<span style="color: #ff0000;">0000</span>0000<span style="color: #00ff00;">5005076719d163d844544e313436</span> |
|
1 |
vmhba0:1:0:1 -> vml.02<span style="color: #ff0000;">0000</span>0000<span style="color: #00ff00;">5005076719d163d844544e313436</span>:1 |
|
1 |
vmhba32:1:3:0 -> vml.02<span style="color: #ff0000;">0003</span>0000<span style="color: #00ff00;">600144f07ed404000000496ff8cd0003434f4d535441</span> |
|
1 |
vmhba32:1:3:1 -> vml.02<span style="color: #ff0000;">0003</span>0000<span style="color: #00ff00;">600144f07ed404000000496ff8cd0003434f4d535441</span>:1 |
|
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, но это не совсем он.
|
1 |
[root@vh1 root]# hexdump -C -s 0x100000 -n 800 /dev/sdf1 |
|
1 |
00100000 0d d0 01 c0 03 00 00 00 10 00 00 00 02 16 <span style="color: #ff0000;">03</span> 00 |................| <span style="color: #ff0000;"><- LUN ID</span> |
|
1 |
00100010 00 06 <span style="color: #993300;">53 55 4e 20 20 20 20 20 43 4f 4d 53 54 41</span> |..SUN COMSTA| <span style="color: #993300;"><- Target Label</span> |
|
1 |
00100020 <span style="color: #993300;">52 20 20 20 20 20 20 20 20 20 31 2e 30 20</span> <span style="color: #00ff00;">60 01</span> |R 1.0 `.| <span style="color: #00ff00;"><- LUN GUID</span> |
|
1 |
00100030 <span style="color: #00ff00;">44 f0 7e d4 04 00 00 00 49 6f f8 cd 00 03 43 4f</span> |D.~.....Io....CO| |
|
1 |
00100040 <span style="color: #00ff00;">4d 53 54 41</span> 00 00 00 00 00 00 00 00 00 00 00 00 |MSTA............| |
|
1 |
00100050 00 00 00 00 00 00 00 00 00 00 00 02 00 00 00 <span style="color: #ff00ff;">fc</span> |................| <span style="color: #ff00ff;"><- Volume Size</span> |
|
1 |
00100060 <span style="color: #ff00ff;">e9 ff 18</span> 00 00 00 01 00 00 00 8f 01 00 00 8e 01 |................| |
|
1 |
00100070 00 00 91 01 00 00 00 00 00 00 00 00 10 01 00 00 |................| |
|
1 |
00100080 00 00 d8 6c 71 49 b0 aa 97 9b 6c 2f 00 0d 60 d4 |...lqI....l/..`.| |
|
1 |
00100090 6e 2e 6e 89 19 fb a6 60 04 00 a7 ce 20 fb a6 60 |n.n....`.... ..`| |
|
1 |
001000a0 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| |
|
1 |
001000b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| |
|
1 |
* |
|
1 |
00100200 00 00 00 f0 18 00 00 00 90 01 00 00 00 00 00 00 |................| |
|
1 |
00100210 01 00 00 00 <span style="color: #3366ff;">34 39 37 31 36 63 64 38 2d 36 30 37</span> |....<span style="color: #3366ff;">49716cd8-607</span>| <span style="color: #3366ff;"><- SEG UUID in ASCII</span> |
|
1 |
00100220 <span style="color: #3366ff;">35 38 39 39 61 2d 61 64 31 63 2d 30 30 30 64 36</span> |<span style="color: #3366ff;">5899a-ad1c-000d6</span>| |
|
1 |
00100230 <span style="color: #3366ff;">30 64 34 36 65 32 <span style="color: #000000;">65</span></span> 00 00 00 00 00 00 00 00 00 |<span style="color: #3366ff;">0d46e2e</span>.........| |
|
1 |
00100240 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| |
|
1 |
00100250 00 00 00 00 <span style="color: #3366ff;">d8 6c 71 49 9a 89 75 60 1c ad 00 0d</span> |.....lqI..u`....| <span style="color: #3366ff;"><- SEG UUID</span> |
|
1 |
00100260 <span style="color: #3366ff;">60 d4 6e 2e</span> 01 00 00 00 e1 9c 19 fb a6 60 04 00 |`.n..........`..| |
|
1 |
00100270 00 00 00 00 8f 01 00 00 00 00 00 00 00 00 00 00 |................| |
|
1 |
00100280 8e 01 00 00 00 00 00 00 64 cc 20 fb a6 60 04 00 |........d. ..`..| |
|
1 |
00100290 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| |
|
1 |
001002a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| |
Кроме заголовка, у нас есть еще и скрытые метаданные, которые мы можем рассекретить с помощью команды ls -al. Файл vh.sf содержит UUID нашего раздела, а также информацию о секторах.
|
1 |
[root@vh1 ]# hexdump -C -s 0x200000 -n 256 /vmfs/volumes/<span style="color: #3366ff;">49716cd8-ebcbbf9a-6792-000d60d46e2e</span>/.vh.sf |
|
1 |
00200000 5e f1 ab 2f 04 00 00 00 1f <span style="color: #3366ff;">d8 6c 71 49 9a bf cb</span> |^../......lqI...| <span style="color: #3366ff;"><- VMFS UUID</span> |
|
1 |
00200010 <span style="color: #3366ff;">eb 92 67 00 0d 60 d4 6e 2e</span> 02 00 00 00 <span style="color: #99cc00;">73 73 32</span> |..g..`.n.....<span style="color: #99cc00;">ss2</span>|<span style="color: #ffff00;"> <span style="color: #99cc00;"><- Volume Name</span></span> |
|
1 |
00200020 <span style="color: #99cc00;">2d 63 73 74 61 72 2d 7a 73 30 2e 32</span> 00 00 00 00 |<span style="color: #99cc00;">-cstar-zs0.2</span>....| |
|
1 |
00200030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| |
|
1 |
* |
|
1 |
00200090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 00 |................| |
|
1 |
002000a0 00 00 00 10 00 00 00 00 00 d8 6c 71 49 01 00 00 |..........lqI...| |
|
1 |
002000b0 00 <span style="color: #3366ff;">d8 6c 71 49 9a 89 75 60 1c ad 00 0d 60 d4 6e</span> |..lqI..u`....`.n| <span style="color: #3366ff;"><- SEG UUID</span> |
|
1 |
002000c0 <span style="color: #3366ff;">2e</span> 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| |
|
1 |
002000d0 00 00 00 01 00 20 00 00 00 00 00 01 00 00 00 00 |..... ..........| |
|
1 |
002000e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| |
Поищем информацию о секторах и типе раздела:
|
1 |
hexdump -C -n 256 /dev/sdf1 |
|
1 |
00000000 fa b8 00 10 8e d0 bc 00 b0 b8 00 00 8e d8 8e c0 |................| |
|
1 |
00000010 fb be 00 7c bf 00 06 b9 00 02 f3 a4 ea 21 06 00 |...|.........!..| |
|
1 |
00000020 00 be be 07 38 04 75 0b 83 c6 10 81 fe fe 07 75 |....8.u........u| |
|
1 |
00000030 f3 eb 16 b4 02 b0 01 bb 00 7c b2 80 8a 74 01 8b |.........|...t..| |
|
1 |
00000040 4c 02 cd 13 ea 00 7c 00 00 eb fe 00 00 00 00 00 |L.....|.........| |
|
1 |
00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| |
|
1 |
* |
|
1 |
000001b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 |................| |
|
1 |
000001c0 03 00 <span style="color: #ff0000;">fb</span> fe ff ff <span style="color: #00ff00;">80</span> 00 00 00 <span style="color: #3366ff;">72 ef bf 5d</span> 00 00 |..........r..]..| <span style="color: #ff0000;">Type</span> <span style="color: #00ff00;">Start</span> <span style="color: #3366ff;">End</span> |
|
1 |
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-раздела.
а как быть если для vmhba2:0:0:0 нарушилась геометрия?
Добрый вечер. Не понял вопроса.
На ESXi 3.5 U4 djpybrkf ошибка бут сектора. После зауска установки с дистрибутива выбрал repaire установка прошла успешно, но inventory пуст, есть ли решения данной проблемы? как вытянуть образы машин из слитого посекторно хранилища?
Подозреваю, что вам необходимо сначала восстановить хранилище из посекторной копии.
Вроде бы подобная команда…
dd if=/var/log/part-backup-sdd.hex of=/dev/sdc bs=512 count=1
Помогите побороть ошибку. 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 |…………….|
*
В чем может быть причина?
http://vinf.net/2009/10/29/iscsi-lun-is-very-slowno-longer-visible-from-vsphere-host/
Посмотри по этой ссылке
vmkfstools-L targetreset уже пробовал – безрезультатно.
Не понятно, как fdisk что-то находит, если hexdump выдает такой мусор, еще и не весь сектор показывает.
Можно-ли вытянуть из этого раздела VMDK файл?
Добрый день!
Я увеличил объем iSCSI-тома на стороне хранилища, теперь пытаюсь увеличить Datastor на стороне ESX-сервера. Сервер по-прежнему показывает Capacity старого размера. Как сделать расширить Datastor на весь объем тома?
Спасибо!
Какая версия ESX/ESXi?
Версия ESX 4.0.0
завтра постараюсь проверить
Жаль, что не удалось проверить 🙁
https://vmind.ru/2010/04/15/kratkij-gajd-po-vmfs-extendextent/
Павел, специально для тебя 😉
А как можно побороть такую проблему: после неясного глюка часть вируальных машин перешла в состояние 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. Возможно глюк на дисковой полке вызвал это.
Хост пробовал перезагружать? Возможно, виртуалки просто “зависли”?
Да, конечно перегружал.
Раздел собирал из 2ТБ или (2ТБ-512байт)?
Попробуйте этот рецепт (http://conshell.net/wiki/index.php/Recovery_of_Locked_VMDK)
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
Т.е. надо как-то чекать файловую систему на полке
Возможно, косяк случился из-за размера. C другой стороны, обычно косяк с VMFS случается, когда происходит ее увеличение. Вы же использовали Extent (если я правильно понял).
Попробуйте на английском VMware Community написать.
Так прличное время все работало без проблем.
Написал уже. Пока тишина.
http://communities.vmware.com/thread/268366?tstart=0
коллеги, а как можно восстановить удлённые файлы с vmfs раздела?
1) Из резервной копии;
2) В ESX3,5U3 появился скрипт VMFS-undelete, но он требует некоторых действий перед тем, как начать восстановление. Насколько я понял, без этих действий данные он не восстановит.
привет! спасибо за ответ! но…
1) данные потерялись именно из-за восстановления из backup(((
(ниже опишу ситуацию)
2) в ESX v4 u2 нет такой комманды((( и потом она требует созданных ранее таблиц раздела vmfs((( что в данном случае выглядит именно как “поздно пить боржоми, когда почки отвалились”.
так вот ситуация такая:
в veeam создан бэкап ВМ, но только одного её диска (системного) остальные подключенные виртуальные HDD в бэкап не включены в виду большого объёма (2 по 250гиг). при восстановлении из бэкапа чтобы не плодить виртуалки и не делать потом лишних телодвижений решено было восстановить ВМ с тем же именем (что в принципе согласитесь логично – выключили требующую восстановления ВМ – восстановили из бэкапа – включили – ВМ вновь в строю) система предупреждает, что ВМ с таким именем существует и спрашивает перезаписывать ли её. здесь-то и кроется “подстава”((( если согласиться перезаписать, то veeam удаляет полностью папку ВМ со всем её содержимым и состанавливает на её место то, что есть в бекапе. соответственно системный диск есть (восстановлен) а остальные подключённые к ВМ HDD были успешно удалены при восстановлении.
Вот такая вот ситуация, парадоксальная до слёз – “Потеря данных при восстановлении”
Теперь ищу как восстановить удалённые с vmfs раздела vmdk файлы, но поиски пока к сожалению тщетны((( Один ли Ontrack предлагает решить проблему за нехилое бабло(((
Я правильно понял, что у вас в папке с ВМ лежали два VMDK-файла, каждый по 250ГБ?
Сочувствую.
Как мне кажется, лучше обратиться в тех.поддержку VMware – это дешевле, чем покупать Ontrack.
Буду ждать новостей.
Успехов!
Всем доброго дня. Извиняюсь за много букв, но хочется сразу обрисовать картину максимально подробно и прошу помощи специалистов
Админ “грохнул” диск 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 внутри неё занял “своё” место?
Заранее благодарен за любую консультацию и готов предоставить дополнительную информацию и “отдаться” в правильные руки в том числе на договорных условиях
Добрый день.
К сожалению, других идей у меня нет.
Вроде бы в телеграм-чате VMGURU кто-то обращался в техподдержку с просьбой восстановить данные, содержавшиеся в удаленном снапшоте.
И там даже ему как-то помогли, но…
увы…
Что-то рекомендовать я не могу.
Если как-то получится восстановить данные – пожалуйста, расскажите и нам.
Что-то я не нашёл этот канал. Есть сайт http://www.vmgu.ru, но на нём никаких отсылок в телеграм я не вижу. Можете прислать имя группы, если не затруднит?
https://vmind.ru/2020/12/03/lyubimye-nashi-gruppy-v-telegram/