Причем если начать создавать новый VMFS раздел на этих LUN'ах, будет указано, что они пустые и никакого VMFS там нет (только осторожнее с этим, не нажмите случайно "создать"). Если при переезде не были физически убиты диски и ничего страшного не случилось, то скорее всего немножко слетело разбиение разделов, которое можно быстро и просто поправить.
Уточним ситуацию (все манипуляции производятся с ESX сервера).
Определяем какой именно раздел надо править.
[root@esx2 root]# esxcfg-vmhbadevs
vmhba0:0:0 /dev/cciss/c0d0
vmhba1:0:1 /dev/sda
vmhba1:0:15 /dev/sdb
vmhba1:0:16 /dev/sdc
vmhba1:0:23 /dev/sdd
vmhba1:0:26 /dev/sde
vmhba1:0:27 /dev/sdf
[root@esx2 root]# fdisk /dev/sda
The number of cylinders for this disk is set to 127482.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
(e.g., DOS FDISK, OS/2 FDISK)
Command (m for help): p
Disk /dev/sda: 1048.5 GB, 1048577048064 bytes
255 heads, 63 sectors/track, 127482 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
Система не видит ни одного раздела, значит ей надо помочь.
Command (m for help): n
Command action
e extended
p primary partition (1-4)
p
Partition number (1-4): 1
First cylinder (1-127482, default 1):
Using default value 1
Last cylinder or +size or +sizeM or +sizeK (1-127482, default 127482):
Using default value 127482
Command (m for help): t
Selected partition 1
Hex code (type L to list codes): fb
Changed system type of partition 1 to fb (Unknown)
Command (m for help): x
Expert command (m for help): b
Partition number (1-4): 1
New beginning of data (63-2047998329, default 63): 128
Expert command (m for help): w
The partition table has been altered!
Calling ioctl() to re-read partition table.
Syncing disks.
[root@esx2 root]# vmkfstools -V
Теперь проверяем, VMFS раздел должен появиться.
!!! Внимание !!!
Все манипуляции необходимо проводить на снапшоте LUN'а, если есть поддержка данной функциональности на вашей SAN.
Первое, что необходимо сделать после восстановления доступа к VMFS разделу со снапшота - полный бэкап всех виртуальных машин (ну или только особо нужных) путем простого копирования. И только после этого можно проводить операцию на "живом" LUN'е.
P.S. у вас до сих пор не настроены бэкапы?
Сообщения
А не пробовал восстанавливать VMFS том, случайно удаленный из клиента? Как вообще происходит его удаление (когда делаем DataStore remove), просто трется сигнатура тома, его ID, ну и может быть MBR LUNа, или происходит как-то более глобально и невосстановимо? На ext3 например (в отличии от ext2) удаление файла выполняет не только unlink i-node, но и забивает нулями блоки данных, поэтому пытаться восстановить чего-то удаленное на этой FS (не порушенной FS, а случайно удаленного файла) дело совершенно безнадежное, аналогичная ситуация на xfs.
ОтветитьУдалитьAnton Zhbankov жизнь просто спас, спасибо, чувааааааааааааак ! :)
ОтветитьУдалитьmaniaq, нет, не пробовал. Надо будет покопаться, хорошая идея.
ОтветитьУдалитьwiz, да пожалуйста :) (раскланиваеццо)
Добрый день.
ОтветитьУдалитьОчень похожая проблема, но способ не помог.
Загалиси сервера корректно, через Maintenance mode, shutdown...
после включения в storage нет ни одного внешнего диска из хранилища, хотя в storage adapters LUNы есть
все виртуальные машины на внешних storagах, ни одной не видно, что делать, ума не приложу.
Кто-то сможет помочь?
Вот данные:
[root@vmware02 root]# esxcfg-vmhbadevs
vmhba0:0:0 /dev/sda
vmhba32:4:0 /dev/sdb
vmhba32:4:1 /dev/sdc
[root@vmware02 root]# vdf -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda2 4.9G 1.4G 3.3G 30% /
/dev/sda1 99M 27M 68M 29% /boot
none 132M 0 132M 0% /dev/shm
/dev/sda6 2.0G 122M 1.7G 7% /var/log
/vmfs/devices 567G 0 567G 0% /vmfs/devices
/vmfs/volumes/4975d5fa-462d3d86-fcf8-001aa01836d6
60G 40G 19G 67% /vmfs/volumes/vmware02:storage1
[root@vmware02 root]# fdisk -l
Disk /dev/sda: 72.7 GB, 72746008576 bytes
255 heads, 63 sectors/track, 8844 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/sda1 * 1 13 104391 83 Linux
/dev/sda2 14 650 5116702+ 83 Linux
/dev/sda3 651 8508 63119385 fb Unknown
/dev/sda4 8509 8844 2698920 f Win95 Ext'd (LBA)
/dev/sda5 8509 8577 554211 82 Linux swap
/dev/sda6 8578 8831 2040223+ 83 Linux
/dev/sda7 8832 8844 104391 fc Unknown
Disk /dev/sdb: 268.4 GB, 268435456000 bytes
255 heads, 63 sectors/track, 32635 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/sdb1 1 32635 262140573+ fb Unknown
Disk /dev/sdc: 268.4 GB, 268435456000 bytes
255 heads, 63 sectors/track, 32635 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/sdc1 1 32635 262140573+ fb Unknown
Вот здесь довольно глубоко описан один из вариантов решения проблемы.
ОтветитьУдалитьhttp://blog.laspina.ca/ubiquitous/understanding-vmfs-volumes
Есть перевод на нашем блоге
ОтветитьУдалитьhttp://vmind.ru/2009/03/30/vmfs-razdely-likbez/
Огромное спасибо откликнувшемся.
ОтветитьУдалитьПроблему решал находясь в отпуске, удаленно, да еще и ночью.
Решение нашел более простое вот тут:
http://www.ivobeerens.nl/?p=286
Вдруг кому пригодится ;-)
К сожалению, не все так гладко. Свежепоставленный хост вдруг ни с того ни с сего потерял сторадж, симптомы аналогичные тем, что описаны выше - но к сожалению, не помог ни один из описанных по ссылкам способов - манипуляции с advanced settings не помогли, а после восстановления таблицы разделов VMFS раздел в итоге появился, но пустой. :(
ОтветитьУдалитьХорошо что на хранилище еще ничего не было "из продакшена", а не то это был бы знатный капец...
Помогите побороть ошибку. LUN видно, Datastore - нет. Пробовал Ваш рецепт - не помогло. (раздел был виден изначально, пришлось вначале удалить). После этих операций, в логе стали появляться записи:
ОтветитьУдалитьFSS: 3702: No FS driver claimed device 'naa.60050cc00061022f0000000000000014:1': Not supported
Что удивительно, вывод
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 |…………….|
*
В чем может быть причина?
Вот буквально вчера-сегодня развлекался тем, что пытался как-то выяснить - что случилось с датастором после того как вырубилось электричество и сервер отказался загружаться.
ОтветитьУдалитьПосле N часов было обнаружено, что сигнатура раздела съехала ровно на 60 000 байт назад. Вместо 100 210 стала располагаться по адресу 40 210.
Всем привет. Устроился на работу, первый раз столкнулся с vmware. У меня такая же проблема, подскажите пожалуйста. Где именно нужно прописывать на ESX сервере эти волшебные строки. Если можно ответ на taztingo@yandex.ru спасибо зараннее огромное
ОтветитьУдалить