В этот раз критическая ошибка Stop: 0x0000007B появилась при попытке установки ОС Windows Server 2003 с жесткими дисками на SCSI интерфейсе. Думал, что вышли из строя жесткие дески. Проверил. Один действительно умер, как раз загрузочный с операционной системой. Я пытался установить на оставшийся SCSI жесткий диск Windows Server 2003, но ошибка Stop: 0x0000007B постоянно выскакивала. Я уже и CMOS сбросил и перерыл почти все настройки BIOS.
Пробовал, конечно и способ, который раньше описывал в блоге Неисправности компьютера в статье Экран смерти *** Stop: 0x0000007B inaccessible_boot_device. Пробовал скормить при установке Windows серверу драйвер жесткого диска по кнопке F6 на дискетке - ни в какую. Купили IDE HDD. Вставил, подключил. Опять та же история.
Все это время я для установки использовал один и тот же DVD диск для загрузки. Оказалось, что дело было в нем. Вставил обычный древний CD с Windows Server 2003 без всяких сервис паков и всё заработало. Думаю, что проблема была в том, что на DVD диске просто не было нужных драйверов, которые тихонько пылились на стареньком CD.
Читать в блоге Неисправности Компьютера:
Samsung тестирует мини SSD для ноутбуков и нетбуков (mSATA стандарт)
ACPI\IPI0001\0 - HP NULL IPMI Controller | Драйверы на сайтах производителей
ID код Plug and Play устройства в сведениях о системе Msinfo32
У меня наконец-то дошли руки написать о том, как виртуализировать SCO OpenServer. Все что я буду писать ниже актуально и для SCO UnixWare.
Когда я решил заняться виртуализацией этой ОС многие коллеги недоумевали над тем какая муха меня укусила. Понятно, что ты периодически рассказываешь о жизни Linux под Hyper-V, но зачем берешься за такую древность как системы от SCO? Некоторые ИТ специалисты даже удивлялись, что компания SCO до сих пор жива и чувствует себя вполне нормально. Они думали, что после банкротства в 2007 году компания перестала существовать.
Ответ на эти вопросы очень прост. История компании SCO насчитывает не один десяток лет и хранит в себе следы взлетов и головокружительных падений. Долгое время SCO была одним из главных поставщиков Unix ОС для крупнейших компаний этой планеты. В результате деятельности SCO ее ОС внедрены и работают по сей день в 87 странах. Общее количество ныне работающих серверов OpenServer приблизительно 2 миллиона. Традиционно потребителями продукции этой компании являются финансовые учреждения, силовые структуры, государственные организации и телеком компании.
Думаю вы согласитесь что перечисленные выше организации весьма консервативны и зачастую не склонны тратить деньги в погоне за новыми веяниями в ИТ индустрии. Поэтому у многих из них до сих пор функционирует SCO OpenServer или SCO UnixWare. Под эти ОС написано множество ПО, которое успешно работает. Переписывать его никто не собирается. Более того часто складывается ситуация что миграция на более современные ОС и портирование ПО потребует таких затрат что затея становится экономически невыгодной.
Но есть одна проблема аппаратное обеспечение серверов на которых установлена ОС OpenServer постепенно изнашивается и приходит в негодность. Находить сменные комплектующие не так уж и просто, да и цены на сертифицированное SCO оборудование не выглядят дешевыми. А тем временем производители аппаратного обеспечения на основе серверов с процессорной архитектурой x86 не зря едят свой хлеб и выпускают все более мощные конфигурации серверов, постоянно снижая цены. Получается, что удобнее консолидировать экземпляры работающих ОС от SCO на более мощном оборудовании с помощью виртуализации. Вдобавок к выгодам от оборудования мы получаем резервное копирование с помощью SC DPM, отказоустойчивую кластеризацию с Live migration и централизованное управление с помощью SC VMM.
Делается это довольно легко. Читаем документ вот тут http://www.sco.com/products/openserver507v/hyperv/
Скачиваем эталонный образ виртуальной машины SCO OpenServer 5.0.7V для Hyper-V
Обратите внимание на букву V в названии версии она означает что данная версия ОС содержит драйвера необходимые для работы под управлением системы виртуализации.
После скачивания распаковываем виртуальную машину и импортируем ее в Hyper-V
Как видите по умолчанию ресурсов ей выдано довольно мало. Версия 5.0.7V поддерживает до 4ГБ ОЗУ так что если для выполнения ваших задач необходимо больше памяти дайте ее виртуальной машине..
После запуска система начинает автоконфигурирование
Сетевые настройки можно задавать статически или с помощью DHCP. Оба способа работают одинаково хорошо.
Затем нужно настроить систему безопасности, создать пароли и при желании установить дополнительные языки. Делается это очень просто поэтому останавливаться на этом не буду.
После окончания установки и перезагрузки на экране увидим следующее.
Сеть, видео и прочие устройства работают вполне надежно и отлично справляются со своими функциями.
Сеть я тестировал побродив по сайту Microsoft. Затем установил пакет Samba и с помощью него передал между SCO OpenServer и Windows несколько десятков гигабайт разных файлов. На это пришлось потратить довольно внушительное время т.к внутри виртуальной машины доступен сетевой адаптер с пропускной способностью 100 мбит которого вполне хватает для выполнения большинства задач. Зато теперь могу сказать что сетевая подсистема работает как часы.
Обратите внимание что потребление ресурсов процессора при этом минимально.
Как мигрировать приложение из существующих в вашей инфраструктуре серверов в виртуальные описано тут http://ds45.blogspot.com/2009/07/sco-p2v-in-real-life.html
На этом рассказ о виртуализации SCO OpenServer можно заканчивать. Надеюсь он пригодися вам если вы решите сэкономить на поддержке унаследованных Unix систем.
Виртуализация основных бизнес приложений все сильнее и прочнее входит в нашу жизнь, меняя привычные методы управления инфраструктурой. Еще пару лет назад я рекомендовал слушателям на семинарах Techdays виртуализировать SQL Server только в случае крайней необходимости и если нагрузка на SQL не велика. Технологии не стоят на месте, и теперь виртуализация БД становится обыденностью. Более того официальную поддержку получает сценарий переноса SQL Server работающего в виртуальной машине с одного узла кластер на другой без прерывания обслуживания клиентов. Делается это с помощью механизма Live Migration. Таким образом, мы легко повышаем отказоустойчивость SQL Server.
Все это описано в документе "Planning, Implementing and Supporting SQL Server Virtualization with Windows Server 2008 R2 Hyper-V and Live Migration"
Внутри документа вы найдете четыре секции позволяющие легко выполнить планирование, внедрение в виртуальной среде или миграцию существующего SQL Server из физической среды в виртуальную. В заключении вы прочитаете о том как лучше всего управлять виртуальным SQL.
Планирование. В этой секции подробно описаны варианты разных стратегий виртуализации SQL Server. Затем рассказывается как обследовать ранее развернутые в организации варианты SQL Server. В зависимости от того что вы обнаружили документация дает рекомендации по подбору оборудования для Hyper-V способного выдержать требуемую нагрузку.
Во второй части подробно описывается как использовать средства P2V (Physical-to-Virtual ) миграции для переноса SQL Server из физической в виртуальную среду. Так же в этой части описан по шагам процесс создания новой виртуальной машины с SQL Server на борту.
Отказоустойчивость и Live Migration тема третьей части. Оказывается обеспечить высокую надежность виртуальным машинам с SQL Server довольно просто, если соблюдать рекомендации.
Последняя часть рассказывает о нескольких правильных стратегиях помогающих управлять SQL Server в виртуальной среде. В том числе затрагиваются и темы мониторинга жизнедеятельности SQL Server с помощью Operations Manager и защиты данных с помощью System Center Data Protection Manager.
Надеюсь все что я описал, поможет вам легко и беспроблемно виртуализировать SQL
Недавно я писал о выходе версии 2.1 сервисов интеграции Linux для Hyper-V. Изменений и улучшений по сравнению с прошлой версией довольно много. С появлением нового функционала изменилась и процедура установки сервисов интеграции в гостевые машины на основе Linux. Поэтому, сегодня я опишу, как устанавливать их в SLES 11. Все, что вы встретите в этом тексте одинаково актуально как для 32-х битных так и для 64-х битных версий SLES 11.
Начальная установка SLES 11 под Hyper-V довольно тривиальна. Главное не забыть выбрать опцию “Physical machine (Also for Fully Virtualized Guests)” и установить инструменты разработки “C/C++ Compiler and Tools”. Они пригодятся нам в дальнейшем для сборки модулей ядра.
Пока сервисы интеграции не будут установлены синтетический сетевой адаптер будет не доступен. Если вам нужно в этот промежуток времени работать с сетью, добавьте виртуальной машине сетевой адаптер “Legacy Network”.
После этого можно продолжать установку гостевой ОС в обычном режиме. По окончанию установки можно настроить сеть и проверить как работает доступ в Интернет.
Как видите, все отлично работает и нам доступна сеть через Legacy адаптер. На этом можно считать начальную установку гостевой ОС завершенной.
Поэтому переходим к самой сложной части – установке интеграционных сервисов, которые дадут нам возможность использовать быстрые виртуальные HDD и гигабитные синтетические сетевые адаптеры.
Скачиваем пакет Linux Integration Services 2.1. Распаковываем его и внимательно читаем инструкцию. Обратите внимание, что установка интеграционных сервисов для SLES 11 и SLES 10 SP3 довольно сильно отличается. Про установку под SLES 10 SP3 я напишу отдельную заметку позже.
Процедура установки интеграционных сервисов в официальной документации описана, по моему мнению, несколько запутано. Это затрудняет ее понимание и правильное применение. Поэтому рекомендую пользоваться мгновенными снимками Hyper-V, на случай если захочется отменить сделанные по ошибке изменения.
Отредактируйте файл /etc/modprobe.d/unsupported-modules так чтобы в нем была следующая строка:
allow_unsupported_modules 1
Перезагружаем виртуальную машину. Подключаем пакет с сервисами интеграции как DVD в виртуальную машину. В моей системе включено автоматическое монтирование, если в вашей системе не так, то возможно придется воспользоваться командой mount.
Создаем служебную директорию /opt/linux_ic и копируем исходные тексты модулей. Проводим компиляцию, устанавливаем их и перезагружаемся.
# mkdir /opt/linux_ic # cp –R /mnt/cdrom/* /opt/linux_ic # cd /opt/linux_ic # make # make install # reboot
После перезагрузки можно увидеть, что в системе появился новый сетевой адаптер seth0.
Плюс к этому нужно проверить все ли модули загрузились с помощью команд
# lsmod | grep vsc
# modinfo vmbus
· Как видите, в системе появились модули netvsc, storvsc, blkvsc, vmbus.
Затем отредактируйте файл /etc/fstab и замените все секции, начинающиеся с /dev/disk/* на эквиваленты в формате /dev/hd* чтобы содержимое файла выглядело примерно так:
Отредактируйте файл /boot/grub/menu.lst и измените, опции загружаемого по умолчанию ядра, так чтобы они указывали на дисковые устройства с новым наименованием:
root=/dev/hda2 resume=/dev/hda1
Приведите файл /etc/modprobe.d/unsupported-modules в первоначальное состояние, установив 0 в качестве значения опции allow_unsupported_modules.
Перезагрузите систему и наслаждайтесь выросшим быстродействием.
Для того чтобы у вас не возникло сомнений в том что SLES нормально чувствует себя под Hyper-V не только в лабораторных условиях, и пригоден для серьезных вычислительных задач, я дал виртуальным машинам по 4 процесора и как можно больше оперативной памяти. К сожалению в моем физическом сервере всего 16 гигабайт памяти, поэтому виртуальной машине удалось дать максимум 15. Что из этого получилось вы можете посмотреть ниже.
Как видите процедура установки интеграционных сервисов не так уж и сложна. Чтобы, в дальнейшем избежать ее рекомендуется клонировать виртуальную машину и в дальнейшем использовать ее как шаблон для новых машин.
