admin.txt

… заметки IT’шника…

Перезапуск зависшего iSCSI инициатора на ESXi

Иногда есть необходимость подключить к ESXi хосту временный датастор для проведения разных маневров. По большей части я стараюсь в таких случаях использовать NFS, но иногда приходится и iSCSI использовать.

Вот вчера столкнулся с девайсом от NetGear  — ReadyNAS Pro 6. Который как оказалось не работает сESXi 5.0 на прошивке 4.2.19 ( но поэто я уже потом нагуглил, когда столкнулся с проблемами: http://forum.netgear.ru/viewtopic.php?id=3295).

Суть в том что настройка программного iSCSI инициатора ESXi прошла просто, а вот переместить туда вируталку или скопировать какой-нибудь файл не получалось. Процесс копирования зависал, а графики показывали дикое время отклика (десяти тысяч миллисекунд). А через некоторое время выскочило сообщение что датастор на iSCSI луне стал недоступен. И никакие ресканы не помогали, процесс очень долго тупил и не мог успешно завершиться.

После поиска в гугле вышел на такое решение (Restarting the software iSCSI stack). Включаем SSH на ESXi хосте и  подключившись туда:

1.  Отключаем программный инициатор:

esxcfg-swiscsi -d

2. Убиваем процесс

esxcfg-swiscsi -k

А потом еще  находим ID процесса и убиваем его

2.а Что бы найти ID: ps | grep vmkiscsid

2.б Что бы убить процесс: kill <process ID>

3. Снова запускаем инициатор: esxcfg-swiscsi -e

4. Делаем рескан нужного адаптера, в моем случае это быо vmhba35: esxcfg-rescan vmhba35

После всего этого лун снова стал доступен. Еще немного поэксперементировав я повторно пришел к проблеме и повторил решение. После чего уже нагуглил пост о несовместимости этой прошивки девайса с пятой весией ESXi.

Пришлось отказаться от iSCSI в данном случае. Кстати отключать LUN iSCSI тоже нужно правильно: Unpresenting a LUN in ESXi 5.x

Реклама

Июнь 7, 2012 Posted by | Заметки..., Uncategorized, Virtualization | , | Оставьте комментарий

Импорт в ESXi всех виртуальных машин с датастора.

Импорт в онсастку ESX(i) вирутальных машин из датастора можно сделать из контекстного меню .vmx файла виртуальной машины (выбрав Browse Datastore,  и найдя нужный файл. Но если таких машин больше несколькоих десятков, а то и сотни — на выполнение этих рутинных операций в ручную можно потратить много часов времени.

Мне пришлось переустановить один сервер с ESX 3.5 на ESXi 3.5 сохранив все виртуальные машины на отдельных датасторах (это были локальные диски, но ситуация не отличилась бы и в слуачае NAS/SAN хранилища).  Замечу, для того что бы подключить к новой инсталяции ESXi 3.5 старые диски с сохранением существующих VMFS разделов нужно на новом хосте в конфигурации выбрав «Advanced Settings», в разделе «LVM» изменить опцию «LVM.EnableResignaturing» c нуля на единицу и сделать Rescan всех котроллеров систем хранения с опцией поиска новых VMFS разделов.

Собстевнно массовый импорт машин для ESX хоста описан тут: Mass Import VMs to New ESX Host by .VMX files, там приведено два способа.

Первый способ — сделать скрипт.

for i in `find /vmfs/volumes/ -name "*.vmx" `
do
echo "Registering VM $i"
vmware-cmd -s register $i
done

Скрипт нужно сохранить, например, как massImport.sh, дать ему права на выполнение (chmod +x /path-to-script/massImport.sh) и выполнить. У этого решения свой недостаток — если в пути/имени виртуалки содержатся пробелы, то ничего не получится. Эта проблема решается во втором варианте.

Второй — одной строкой из консоли ESX:

find /vmfs/volumes -name “*.vmx” | while read LINE; do echo “registering VM $LINE”; vmware-cmd -s register $LINE

Но это решения дл ESX, а в моем случае был ESXi. Для ESXi комманды vmware-cmd нету, а на ESX я эти варианты не проверял… Немного погуглив я нашел список команд для работы через SSH/CLI с ESXi. Разрешив из локальной консоли доступ к  ESXi по  ssh, я нашел и протестировал работу аналога нужной команды.

vim-cmd solo/registervm /vmfs/vol/datastore/dir/vm.vmx
Registers vm in hypervisor inventory

т.к. у меня была куча виртуалкок в имени (и пути к VMX файлу) которых содержались пробелы, я решил «поправить» второй способ для работы в ESXi. Эта команда импортирует все виртуальные машины с выбранного датастора «Temp-IT-Drive(1TB)» в «корень» оснастки хоста. Вот что вышло:

find /vmfs/volumes/Temp-IT-Drive\(1TB\)/ -name "*.vmx"| while read LINE; do echo "registering VM $LINE"; vim-cmd solo/registervm "$LINE";done

Пришлось добавить к исходному варианту «;done» в конце и заключить $LINE в ковычки выполнении команды импорта, иначе виртуалки «с пробелами»  все же не обрабатывались.

Вот собственно и все, если есть что добавить — велком в коменты.

Сентябрь 8, 2010 Posted by | Virtualization | , | 2 комментария

Смена настроек DNS на ESXi хостах средствами PowerCLI

Если есть необходимость смены настроек ДНС на сервереах виртуализации ESX(i), то можно пойти двумя путями.

1. В ручную изменить настройки на вкладке «Configuration», разделе «DNS and Routing» каждого хоста виртуализации. Все быстро и просто, пока работы охватывают пару-тройку хостов. А если нужно перенастриоть 10+ серверов нужно «идти в обход».

2. Когда хостов много, а времени на работу в вручную мало/жалко — пора использовать VMware PowerCLI. Я не обладая опытом работы за пару минут нашел способо изменить конфигурацию DNS на нужной мне группе хостов. Итак после загрузки последнего дистрибутива PowerCLI с сайта VMware можно сразу приступать к работе.

После запуска PowerCLI нужно подключиться к хосту, в простейшем случае (если ваш аккаунт имеет права в вашем vCenter) это делается одной командой:

Connect-VIServer -server vCenter-name

После подключения, нужно выполнить следующую команду. В данном примере будет смена адресов DNS сервреов всех хостов в датацентре «MyDataCenter»

Get-VMHost -Location (Get-Datacenter -Name MyDataCenter) | get-vmhostnetwork | set-vmhostnetwork -dnsaddress "192.168.0.1","192.168.0.2"

Ну и стоит отметить, что смена конфигурации DNS на хостах не приводит (по крайней мене в моем слуаче было так) к переключению хоста на новые настройки.  Новые настройки вступят в силу после перезагрузки хоста или после рестарта Management сервисов (services.sh restart из консоли хоста)

Сентябрь 2, 2010 Posted by | Virtualization | , , | Оставьте комментарий

Upgrade virtual hardware с 4 на 7 версию. Как обновить виртуальное железо.

После переезда на VMware vSphere и обновления всех ESX/ESXi  хостов до 4 версии, начал наводить порядок с бэкапами, шаблонами и прочим добром.

Сразу думал что оставлю все старые виртуалки на 4 уровне virtual hardware (новые сразу уже 7 уровня делаю), т.к. много работы по обновлению. Ведь сразу все не сделаешь, да еще и может что-нибудь поломаться. А позднее, вышел на необходимость обновления виртуального железа до 7 уровня, что бы можно было юзать vStorage API, а конкретнее CBT (Changed Block Tracking).

Уже обновив более 20 виртуалок, можно сделать вывод: Windows виртуалки обновляются почти без проблем, Linux — тоже все ОК, а вот Solaris и прочие редкости — сразу ломаюццо (нужен индивидуальный подход с длительним инвестигейтом).

Сразу оговорюсь, что без предварительного бэкапа виртуалки, лучше не поводить обновление виртуального железа. В крайнем случае — сделать снапшот перед началом работ.

Использовать VMware vCenter Update Manager я не рискнул,  т.к. еще не налажены бэкапы виртуалок, может через пару недель попробую.

Итак, планируем обновление VMware Tools и Vitrual Hardware для каждой виртуалки. Потребуется 4 перезагрузки для каждой виртуалки, в течении всего процесса обновления.

Процес стоит проводить в такой последовательности:

  1. Обновить VMware Tools вируталки до актуальной версии. В идеале билд тулзов=билд хоста, но минимальное требование — тулзы от esx\esxi 4. После завершения установки/обновления vmware tools гостевая ос должна перезагрузится (1 ребут). Для этого этапа можно использовать update manager, можно обновить тулзы в автоматическом или интерактивном режиме. В результате мы должны видеть статус ОК на вкладке Summary:

    VMtools Status OK -on HW4

    VMtools Status OK before HW upgrade

  2. Обновить Virtual Hardware, небходимо убедится в корректной установке VMware Tools на виртуалке. Обязательно наличие бэкапа виртуалки.
    Для этого процесса так же можно использовать vCenter Update Manager, или же вручную обновлять уровень виртуального железа (выключив предварительно виртуалку). Этот этап  — 2 ребут.
  3. Перезагрузка Гостевой ОС, после установки всех драйверов на новое виртуальное железо железо (3-й ребут).
    для Windows:  Залогинившись в ОС, сразу после ее загузки (для винды), можно наблюдать поцесс установки драйверов. После завершения устанвоки драйверов должен появится запрос на перезагрузку, если он не появился — нужно ребутнутся вручную.
    При обновлении вируального железа происходит замена виртуальных сетевых адапетеров, настройки сети переносяся со старого адаптера на новый. Но иногда случается глюк, поэтому желательно предварительно сохранить сетевые настройки вируталки (ipconfig -all >c:\ipcongig.txt), или иметь возможность восстановить из другого источника.
  4. Удаление отсутсвующего сетевого адаптера .
    (для Windows) При обновлении вируального железа происходит замена виртуальных сетевых адапетеров, но старые адаптеры все еще «числятся» в системе. Проверить это можно зайдя в TCP\IP настройки нового сетвеого адаптера. Если он настроен на статический IP адрес, то при нажатии на OK будет выеденно предупреждение, что другой сетевой адаптер уже имеет такой IP. Это не вызовет конфликтов в работе, но лучше удалить из системы запись о старом сетвом адаптере.
    сделать это можно так: http://support.microsoft.com/?kbid=269155 или тоже самое но в другом месте
    Кратко — нужно ввести в коммандной строке:
    set devmgr_show_nonpresent_devices=1
    start DEVMGMT.MSC

    И, включив в менеджере устройств отображение скрытых девайсов, удалить «бледный» сетевой адаптер. После этого предупреждение не будет выскакивать.
    (для linux) Тут можно отметить, что иногда сбивается нумерация сетевых адаптеров. Есть солюшены как этого избежать, но я еще не вникал.
    В своих случаях, я просто правил конфиги сети, заменяя номер eth0 на нужный.
  5. Настройка WINS. Нужно заметить, что настройки WINS, если они у вас были, не переносятся со старого интерфейса на новый при обновлении железа. Если нужо — вносим WINS как и было, заодно и проверим, что по нажатию ОК  не появляется сообщения о адаптере с таким же IP.
  6. Финальный ребут (четвертый). Это не обязательно, но если есть возможность — лучше ребутнутся еще раз и проверить что все ок. После этого можно считать работы с виртуалкой завершенными.

Ну и в заключение — нужно иметь ввиду, что после обновления вирутальног железа меняется имя сетевого подключения и MAC адрес. В большинстве случаев это не играет роли, но в некоторых окржениях может иметь значение.

___________________

Источники информации:

P2V — Error with NIC after migration with static IPv

Sphere Virtual Machine Upgrades-public

Март 2, 2010 Posted by | Virtualization | , , , | Оставьте комментарий

Узнать версию VMware Tools, установленных в гостевой ОС Linux.

Для того что бы узнать версию VMware Tools установленных в гостевой операционной ситеме Linux можно применять два способа.

Первый способ, для ОС с установленным графическим интерфейсом, который аналогичен способу применяемому в ОС Windows.

Необходимо запустить vmware-toolbox (из меню или из консоли) в результате чего появится окошко, на одной из вкладок которого можнонайти нужную информацию.

Окошко vmware-toolbox, где можно узнать версию vmtools

Окошко vmware-toolbox, где можно узнать версию vmtools

Второй способ — универсальный, и подходит для серверов (виртуалок) где не установлена графическая среда.

Это единственный  способ (how get vmware tool version linux ), основан на том, что конфигурационный скрипт от vmtools выводит по окончанию своей работы версию (билд) VMware tools. Но что бы не запускать конфигурацию снова и не делать ненужную работу (а возможно и опасную), мы просто ищем номер версии в исходных текстах скрипта. Он хранится там в переменной buildNr.

vm-server:~# grep buildNr /usr/bin/vmware-config-tools.pl
my $buildNr;
$buildNr = '3.5.0 build-110271';
return remove_whitespaces($buildNr);
vm-server:~#


В выводе команды сразу видим нужную информацию, билд тулзов в данном примере 110271… а гипервизор у меня 143129… надо бы обновить.

Апрель 24, 2009 Posted by | Linux, Virtualization | , | 2 комментария

VirtualCenter 2: Использование шаблонов, практика применения.

Наверное всем давно известно о существовании механизма шаблонов, используемого для разворачивания виртуальных машин. Уверен что многие его успешно применяют. Но некоторым будет интересно ознакомится с описанием технологии и практики применения шаблонов в VMware Virtual Center.

Почему стоит использовать шаблоны для разворачивания виртуальных машин.

Первая и простейшая причина применения шаблонов виртуальных машин — это эффективность. Используя механизм шаблонов можно избежать множества повторяющихся при инсталляции приложений операций. В результате можно получить полностью готовый (виртуальный) сервер намного быстрее, чем инсталляция в ручную, с самого начала. Рассмотрим следующий пример: вам необходимо создать четыре виртуальные машины, с гостевой ОС Windows. Причем три из четырех машин планируются для использования в производстве (produciton use), а четвертая — для использования разработчиками. В отличии от трех машин, четвертая не требует использования агента резервного копирования (backup agent). В процессе выполнения задания необходимо будет выполнить 17 шагов, большая часть из которых будет повторятся для каждой виртуалки (см. рисунок).

manual setup of several VM

Ручное разворачивание нескольких виртуальных машин

Это не только отнимет кучу времени на повторяющиеся операции, но и повысит шанс допустить ошибку на одном из шагов. Более эффективный путь — создание базового шаблона операционной системы с антивирусом и обновлениями, и Читать далее

Февраль 20, 2009 Posted by | Virtualization | , , , , , | 2 комментария