Powered By Blogger

пятница, 4 октября 2013 г.

Конвертировать файл .ova на VMware ESXi 5.1

Есть файл виртуальной машины с расширением .ova - созданный предположительно на VirtualBox. Задача запихать эту виртуальную машину на сервер VMware ESXi. 
Нашел что нужно скачать и установить OVFTool, ссылка тут. Далее все должно было решиться простой командой в консоли:

ovftool.exe --lax your.ova your.vmx

Хрен то там! Вываливалась ошибка что-то там про версию VirtualBox. Пошел немного другим путем:

ovftool.exe --lax your.ova your.ovf

Отработала успешно, после этого в папке оказалось несколько файликов: .mf .vmdk и .ovf.

Далее пробовал непосредственно в vSphere Client через File-Deploy OVF Template... подсунуть файлик .ovf. Опять ругается: 

Unsupported hardware family 'virtualbox-2.2'

В интернетах это лечится редактированием файла .ovf - находим строку с "virtualbox-2.2" - и заменяем на "vmx-07"

После этого начинает ругаться на контрольную сумму файла .ovf, которую мы и изменили. Нужно измерить ее и вписать в файл .mf. Измерить можно штукой Microsoft Checksum Verify utility. Консольная штука, мерить просто:

fciv.exe -sha1 your.ovf

После этого открываем блокнотом файл .mf и копируем контрольную сумму.

Далее опять пытался запустить, вылезла ошибка: Line 66: OVF hardware element ‘ResourceType’ with instance ID ’5′: No support for the virtual hardware device type ’20'

Лечиться редактированием файла .ovf, меняем:

<Item>
<rasd:Address>0</rasd:Address>
<rasd:Caption>sataController0</rasd:Caption>
<rasd:Description>SATA Controller</rasd:Description>
<rasd:ElementName>sataController0</rasd:ElementName>
<rasd:InstanceID>5</rasd:InstanceID>
<rasd:ResourceSubType>AHCI</rasd:ResourceSubType>
<rasd:ResourceType>20</rasd:ResourceType>
</Item>

На:

<Item>
<rasd:Address>0</rasd:Address>
<rasd:Caption>SCSIController</rasd:Caption>
<rasd:Description>SCSI Controller</rasd:Description>
<rasd:ElementName>SCSIController</rasd:ElementName>
<rasd:InstanceID>5</rasd:InstanceID>
<rasd:ResourceSubType>lsilogic</rasd:ResourceSubType>
<rasd:ResourceType>6</rasd:ResourceType>
</Item>


Далее опять изменяем контрольную сумму.

Опять ошибка, ругается на устройство с id:35, я просто опять открыл файл для редактирования, нашел раздел с содержанием этого id:35 (кажется было аудио устройство) и просто удалил все начиная от <Item> до </Item>. После этого опять поменять контрольную сумму, и наконец-то удачно импортировал виртуальную машину на VMware ESXi.

Всю полезную информацию нашел тут.


среда, 24 июля 2013 г.

Перенос контроллера домена с 2003 на 2008 r2

Самая долгая и нудная миграция за все время.
Задача была перенести контроллера домена с 2003 на 2008 на одно и то же железо - по сути банальна, но... 

Усложняющий элемент: 2003 поднят на VMware ESXi.; имеется еще один сервер ESXi и есть куча офисных машин, слабеньких по аппаратным характеристикам; сеть 100 мб/с; разделы жесткого диска виртуального сервера по 250 и 300 Гб, сделать все нужно быстро, незаметно для пользователей = в не рабочее время.

Вариантов было несколько, первым делом нужно было освободить физический сервер: 

1. Перетащить 2003 на другой сервер ESXi, дальше делать с нужным железом все что захочется.
2. Поднять ESXi на офисной машине, мигрировать 2003 туда, дальше на сервер поставить 2008-у и т.д.
3. Перетащить 2003 на vmware player...
4. Поднять на офисной машине 2003, передать роли контроллера домена ему, скопировать все файлы (~500 Гб), поставить на сервера 2008 - потом передавать роли снова... - сразу скажу этот вариант был последним, и самым действенным, потому что все пошло по плохому сценарию.

Дополнительные вводные данные:
1. Исходный сервер (на котором стоял ESXi и на который надо поставить 2008 dc) - HP ProLiant ML 310 - груда металла, самая дешевая комплектация, без аппаратного raid, без корзины для дисков.
2. Второй сервер ESXi - сборная солянка на базе МП Supermicro PDSME+, RAID 3ware 9550 x4 без батарейки - херня откровенная, но об этом напишу в другой раз, наверно.

Попытка №1
Самый казалось бы очевидный порядок действий. Из-за медленной сети (100 мб/с) виртуалка мигрировала долго... очень долго (~500 Гб), так долго что через пару часов я понял что "тупанул", отменил копирование, вытащил жесткий диск из исходного сервера и воткнул во второй. После перезагрузки ESXi нашел новый диск, примаунтил его, добавил виртуалку в inventory (ПКМ по файлу *.vmx - могу наврать). В общем запустилось все, но похерил по дороге все виртуальные сетевухи - почему непонятно, версии ESXi были одинаковые - 4 upd 1. Вообще там есть еще кое какие нюансы, когда так по не христиански  переносишь виртуалки, действовал интуитивно.

В общем исходный сервер был освобожден от груза ESXi вместе с жесткими дисками, но в него планировалось вставить 2 новых винта, так что не проблема. 2003 теперь крутилась на другом серваке ESXi, а на исходный я мог ставить 2008 на новые винты.

Чем я и занялся. Сервер должен быть отказоустойчивым, хотя бы по дисковой подсистеме. Без "аппаратного RAID c батарейкой блять!" этого добиться сложно. Черт дернул побаловаться с Embedded RAID (host-raid) - встроенного в материнку ML 310. Поднял зеркалирование на двух новеньких винтах Seagate Constellation ES.2 (2 Тб). Поставил 2008 R2 - не обошлось без подпихивания драйверов контроллера - хорошо что на 2008 это можно сделать через флэшку USB. Еще момент, через диск HP Smart Start система не поставилась, установка "типа" пошла, но потом инсталятор так и не смог увидеть какой-то там файлик и все повисло, поэтому и пришлось ставить "вручную"

Грабли обнаружились не сразу. Система как то откровенно подтормаживала, запустил HD Tune - и вот оно, скорость работы raid ~ 40-50 Мбайт/с - тормоз!
Обновил драйвера, поставил HP PSP, обновил прошивки и биос, через диск HP. Ничего не помогало, скорость работы оставалась прежней. Менял Write Cache через BIOS встроенного райда, эффекта ноль - даже кажется медленнее стало работать. Оставлять так было нельзя, так как на сервере должны были быть файловые базы 1С.

Разобрал райд, убрал один винт, система прогрузилась нормально, даже не заметила что теперь без райда. Изменилась только скорость работы с диском - теперь ~ 120-130 Мбайт/с.

Работу уже было пора заканчивать, а я только поставил систему. Надвигалась гроза, и в целях безопасности я отключил все сервера, вытащил кабели питания - в общем обесточил все.

Гроза прошла, как я и предполагал отключали электричество.

На следующий день включаю сервера - сборная "солянка" Supermicro не заводится. Стартуют винты, но не мамка. Полдня безуспешных попыток реанимировать. Опыта работы с "железом" предостаточно - поэтому могу сказать откровенно - перепробовал все!

К конце второго дня я остался со свежей 2008 на ML 310 и... и все. Даже в домен вогнать не успел, не то что там роли передать... Контроллер домена лежал на винте отформатированном в VMFS.

Попытка №2
Supermicro супер сдох аккурат в четверг утром. Бухгалтерия осталась без баз 1С и без интернета.

Собрав все известные мне маты решил поднять ESXi на чем каком нибудь компе, и запустить виртуальный контроллер домена на нем. Но ни на один комп ESXi не встал, ни 4 версия, ни 4 upd1 ни 5.1 - все время ругался на отсутствие поддерживаемой сетевой карты (которая на Supermicro была вшита в саму плату).

Так как у меня было 2 винта с райда, одинаковых по содержимому, то решил параллельно пробовать два способа. Первый - запустить ESXi на HP ProLiant, второй запустить виртуальную машину через Vmware Player.

Про первый способ особо рассказывать нечего. Воткнул винт с самим гипервизором в HP ProLiant. Все завелось без лишних вопросов. Выключил. Подключил винт с виртуальной машиной. Включил. Настроил IP адреса. Зашел через клиента, добавил диск, добавил виртуальную машину, настроил виртуальную сеть. Все работает. Начал устанавливать 2003 на первую попавшуюся офисную машину.

Во втором случае пришлось повозиться. Так как винчестер с виртуальной машиной был отформатирован в VMFS, то просто подключить его к компу с Windows ничего не даст. Что бы получить доступ к файлам виртуальных дисков *.vmdk пришлось использовать специальный драйвер написанный на Java.
Вот ссылка на источник: тутOpen Source VMFS Driver.
Вкраце, использовать vmfs-tools при загрузке с LiveCD. Или монтировать из Windows.
Установить Java. Выполнить следующие команды:

cd C:\Program Files\Java\jre7\bin
java -jar D:\vmfs_r95\fvmfs.jar
java -jar D:\vmfs_r95\fvmfs.jar \\.\PhysicalDrive3 info
java -jar D:\vmfs_r95\fvmfs.jar \\.\PhysicalDrive3 dir /
java -jar D:\vmfs_r95\fvmfs.jar \\.\PhysicalDrive3 filecopy /FS_Win2003_1/FS_Win2003.vmdk
java -jar D:\vmfs_r95\fvmfs.jar \\.\PhysicalDrive3 filecopy /FS_Win2003_1/FS_Win2003-flat.vmdk
java -jar D:\vmfs_r95\fvmfs.jar \\.\PhysicalDrive3 webdav

Последняя команда расшаривает диск необычным образом, к нему можно получить доступ через браузер. http://localhost:50080/vmfs.

Последним способом я и воспользовался. минус его в том что через браузер диски *.vmdk скачиваются на низкой скорости, примерно 20 Мбайт/с. VMPlayer не запускался, пока не скачал все файлы с папки виртуальной машиной ESXi.

К этому времени уже установился 2003 на офисный комп. На старом выполнил проверку netdiag и dcdiag, были незначительные ошибки, но я решил рискнуть. Роли проверить можно через netdom query fsmo (устанавливается через Support Tools с диска CD2 2003 R2).

Назначил настройки IP свежеустановленному 2003, вбил его в домен. Поднял уровень до КД, вручную добавил роль DNS-сервер, добавил Глобальный каталог. Через окна передал ему все роли FSMO, несколько раз перезагрузил его и старый виртуальный КД. Затем на старом выполнил понижение роли КД (через удаление). Вот единственное что забыл так это удалить его из домена.

Далее уже на новом 2003 выполнил повышение функционального уровня домена и леса до 2003 (до этого стоял 2000) смотреть подробно тут (делается в консоли Домены и отношения доверия Active Directory - ПКМ по домену - Повысить функциональный уровень домена - опять ПКМ - Повысить функциональный уровень леса). И обновил схему леса и домена до 2008 R2 (все это делается на 2003).

Запускается adprep32.exe с диска 2008 R2 (если 2003 х32).

adprep32.exe /forestprep

adprep32.exe /domainprep /gpprep

adprep32.exe /rodcprep

В общем, делал все как тут.

Скажу только что в итоге я не смог передать роль Мастер Схемы, пришлось захватывать (KB M$). Но даже после захвата в логах журнала 2008 были ошибки, что КД является Мастером Схемы, но не уверен до конца что это так. Возможно потому, что 2003 я не смог понизить до рядового сервера. Постоянно вылетала ошибка, пришлось его просто отрубить и удалить из AD.

пятница, 28 июня 2013 г.

Восстановление информации, vmdk - xfs

Пришла беда...
Развалился RAID 1 на 1 Тб SATA винтах.
Контроллер 3ware 9550  SX на 4 SATA порта. Винты Seagate Barracuda 7200.12. Один винт помер окончательно (совсем), при подключении к компу зависало все, даже BIOS не прогружался. Второй был с убийственными показателями SMART и системой не определялся никак.
RAID использовался как хранилище виртуальных дисков *.vmdk для VMware ESXi 4.0. Гостевой системой была Ubuntu Server с файловой системой XFS, на обоих разделах виртуальных дисков. Собственно там было 2 виртуальных диска на 250 Гб и на 680 Гб. Контроллер видел тоже только один диск (физический), сейчас уже не помню что он там писал и предлагал, так как ситуация была "критическая" и информация которая хранилась на дисках была нужна срочно... Было принято решения отцепить диск от 3ware'ного контроллера, подцепить к другому компу и сделать полную копию.
Сейчас уже могу сказать, что главное в такой ситуации это сохранять спокойствие и не поддаваться панике, не реагировать на панику окружающих людей. Лучше совсем остаться одному, и хорошенько все обдумать, прежде чем что то делать. Составить последовательность действий, рассмотреть различные варианты развития событий.
Нашли новый винт на 1 Тб, стали копировать на него через Acronis Server Edition, конечно же загрузившись с LiveCD. Прошло около пяти часов и на 90% выдал ошибку, типа не могу дальше и все. Причем не предлагал пропустить нечитаемые сектора и продолжить. Хорошенько выругавшись, решил работать с тем, что удалось скопировать.
ESXi увидел оба виртуальных диска, хорошо, подумал я. Примаунтил диски к гостевой Linux, он тоже увидел виртуальные диски, и разделы на них, и файловую систему XFS, но маунтить разделы не смог, сыпался ошибками.
Что бы не терять время отрыли еще один винт на 1 Тб и стали лить вторую копию с еле дышащего винта с райда, теперь уже с помощью dd, acronis disk director уже не доверяли.
Легендарная команда: dd if=/dev/sda1 of=/dev/sdb2 bs=4096 conv=noerror 
отпахала почти 6 часов, при этом не показывая никакой информации о происходящем, наконец выдала что скопировано 800 с чем то гигов, еще сколько то гигов не смог скопировать.
Мой коллега потащил вторую копию цеплять к виндовой машине для сканирования через R-Studio. В итоге после 5 часов сканирования R-Studio нашел около 250 т. файлов (искали только *.doc и *.xls). Файлы были с рандомными именами, никакой структуры папок даже не проглядывалось, попадались файлы размером в 300 Гб... Результат можно сказать был "никакой", найти в такой куче нужные файлы было невозможно.

Тем временем первая копия диска ни в какую не хотела маунтиться к системе. xfs_alloc_read_agf и bad magic nimber in super_block - могу сказать что это ничего хорошего не означает, все очень плохо. Скажу только что перепробовал все что только можно. Несколько раз пргонял xfs_repair, с разными параметрами, толку ноль. xfs_check даже не стартовал. Тоже самое было и со второй копией диска, которую отключили от R-Studio - так как результат не устроил никого.

Тогда было решено с клонировать еле живой диск еше раз, теперь уже с помощью dd_rescue.
Прогонял в три захода:

dd_rescue --no-split --verbose /dev/sdb_bad /dev/sda_good /var/res.log
dd_rescue --direct --max-retries=2 --verbose /dev/sdb_bad /dev/sda_good /var/res.log
dd_rescue --retrim --max-retries=2 --verbose /dev/sdb_bad /dev/sda_good /var/res.log

На удивление почти мертвый винт выдержал такое надругательство на собой. Команды нашел в инете на сайте какого-то доброго человека, просто уже не помню где. Сканировал долго, при этом показывал информацию о скорости сканирования, сколько сканировал, об ошибках. Запускалась команда с Hirens BootCD Linux.
На удивление сканировал намного больше, и ошибок было всего 5, около 10 Мб нечитаемой инфы. Может повлияло то что винчестер был "вверх ногами", но не факт =)
После этого все отлично примаунтилось, xfs правда ругнулся на то что надо бы очистить журнал, но с копировалось кажется все.


четверг, 20 июня 2013 г.

Автоматический вход в систему Windows 7 в домене Windows 2003r2


Избитая тема, пишу что бы не забыть:

В системе которая не в домене достаточно ввести:

control userpasswords2
... и выбрать нужного пользователя, убрав галку с требованием ввода пароля при загрузке.

Что бы войти под другим пользователем, при загрузке или при выходе из системы удерживать SHIFT.

Если система в составе домена (проверялось на win7) нужно править реестр.

В ветке:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon

Создать строковые (REG_SZ) параметры:
AutoAdminLogon установите значение 1
DefaultUserName
DefaultDomainName
DefaultPassword


четверг, 13 июня 2013 г.

Восстановление файлов Linux XFS



После беглого гугления понял что восстановить удаленные файлы с XFS невозможно, и что стоит попробовать утилиты scalpel и foremost. Обе установились с родных Ubuntu репозитариев.

Файлы были удалены с сетевого ресурса Samba. Сама Ubuntu Server установлена на VMware ESXi. Система на ext3, примаунтен виртуальный винт на 250 Гб с файловой системой XFS - он и расшарен под сетевые диски.



SCALPEL


Перед запуском редактируем /etc/scalpel/scalpel.conf

Раскоментируем строки с нужными расширениями файлов. Не нашел XLS. Загрустил.

Запускается все дело командой:
scalpel /dev/sdb -o /mnt/dsk2/recovery



Сканируется весь раздел, времени ушло много, скорость судя по всему небольшая. Проц грузил все время на 70-90%. Нашел очень много файлов, но больше половины из них были битыми и не открывались. Все вывалил в одну кучу, с ниочем не говорящими названиями файлов. Как я понял после удаления в Linux уже невозможно восстановить имя файла и дату создания/редактирования.


Так как xls файлы scalpel не умеет? восстанавливать, решил пробовать foremost.


FOREMOST
foremost -v -T -t xls -i /dev/sdb -o /mnt/dsk2/recovery



-v – инфориация о прогрессе сканирования - практически бесполезная штука.

-Т – покажет время в названии папок для восстановленных файлов - ничего не показал (возможно потому что все таки xfs)

-t xls,png,bmp – восстанавливать только файлы нужного типа, например *xls


Просканировал шустро. Вывалил все файлы с рандомными названиями в кучу. Получилось около 5 тысяч excel файлов - дальше разбирайся как хочешь...


Впринципе обе программы справились более менее нормально. Минус конечно что сканировалось все дело долго. В первом случае тулза пыталась сожрать проц. Временами все зависало. Еще минус что на разбор около 10 тысяч файлов, и поиска среди них нужных десяти файликов, уйдет туева хуча времени.


Кстати ни одна программа не работает с файловой системой XFS - по крайней мере не нашел в описании. Еще все осложнялось тем, что диск с которого шло восстановление нельзя было отключать, нельзя также было отключить и сетевой ресурс с которого удалились файлы. Сканирование шло на живую, что естественно недопустимо, по идее, так как и ежу понятно что после "инцидента" раздел нужно отключить, или примаунтить только для чтения. И уже точно никакие файлы на него не записывать.