Перезагрузка FC HBA на хостах ESX(i)

Есть такая проблема. При подключении хоста ESX(i) (замечено на QLogic FC HBA) к новым создаваемым LUNам на некоторых массивах необходима перезагрузка хоста. Т.е., когда вы в vClient пытаетесь подключить только что созданный новый LUN, вы этот раздел не увидите.
Так как перезагрузка хоста бывает делом проблематичным (особенно в продуктиве), есть более быстрый способ: воспользоваться командной строкой HBA-адаптера для перезагрузки самого интерфейса. На ESXi для этого командую строку придется включить.

Процедура выглядит так:

1. Подключаемся к серверу по SSH или входим в консоль сервера ESX(i).


2. Определяем, какие идентификаторы SCSI HBA у нас есть:

# ls -l /proc/scsi/qla2xxx/
-rw-r--r-- 1 root root 131072 Jun 15 09:21 3
-rw-r--r-- 1 root root 131072 Jun 15 09:21 4

В моем примере это 3 и 4 (здесь и далее я их специально выделил цветом).


3. Затем для каждого производим инициацию ("LIP login") для каждого из интерфейсов:

# echo "scsi-qlalip " > /proc/scsi/qla2xxx/3

и

# echo "scsi-qlalip " > /proc/scsi/qla2xxx/4

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


4. Делаем рескан. Либо в vClient, либо командой "esxcfg-rescan", либо запросом на HBA-адаптер:

# echo "scsi-qlascan " > /proc/scsi/qla2xxx/3

и

# echo "scsi-qlascan " > /proc/scsi/qla2xxx/4

5. Проверяем. LUN должен быть виден сервером.



На самом деле проблема встречается не только при презентации LUN, но и при создании/изменении зон SAN и т.п. операциях.

Парольное бремя в ESXi 5. И включение SSH.

Как-то уже писал про локальные пароли ESXi, но то относилось к версии 4.1.
В версии 5 файл с параметрами называется:

/etc/pam.d/passwd

Да, и теперь SSH-доступ включается только в консоли vClient, меню консоли больше нет.

Вот процедура, как это сделать:

vSphere WTFAQ! (или что-такое vSphere)

Я как-то писал про различие между ESX и ESXi. Но недавно стал обращать внимание, что люди путают понятия vSphere и ESX(i), вернее - не понимают, что за зверь такой "ви-Сфера".
Постараюсь объяснить максимально простым языком.


vSphere - это общее название всей платформы виртуализации от VMware.
Технологическая основа этой платформы - гипервизор ESX (или ESXi, часто пишут ESX(i), подразумевая одно и ESX, и ESXi, которые несут одни и те же функции), он же - просто гипервизор, или еще встречается название - vSphere ESX.
Гипервизор занимается только тем, что включает/выключает виртуальные машины (ВМ), да управляет ресурсами физического сервера для этих ВМ (выделяет области оперативной памяти и процессорное время).

Есть еще vSphere vCenter - программа (часто называют программу сервером) для управления группой гипервизоров. Она ставится на Windows, объединяет ESX-ы в так называемые кластеры, и творит основные чудеса виртуализации: мигрирует машины без остановки; объединяет серверы ESX в кластера, чтобы те могли запускать ВМ, если один из гипервизоров вдруг перестанет работать; и т.п.
Все подобные чудеса, надо сказать, доступны при наличии:

1. дисков, доступных всем гипервизорам в кластере (например, отдельное устройство с дисками - система хранения данных)
2. более одного гипервизора, которые будут с помощью vSphere vCenter объединены в кластер
3. лицензии. От типа лицензии будут доступны различные наборы "чудес"

Есть еще различные "vSphere <что-то_там>" - часто это дополнительные программы к vSphere vCenter, которые выполняют свои определенные функции. Называют эти программы семейством программ vSphere vCenter. Для их работы обязательно нужен сервер управления vSphere vCenter.
Но это семейство всегда продается отдельно, и по сути своей не являются частью vSphere, а отдельным техническим решением, для работы которого нужна платформа vSphere.

Но часть vSphere <что-то_там> - это не отдельные программы, а функции работы самого vSphere vCenter или vSphere ESX. vSphere API, например, дает возможность программистам создавать программы так, чтобы они могли получать информацию от платформы виртуализации, или отдавать различные команды платформе.
Понимаю, что это может смутить тех, кто не в теме. Но для этого и есть различные консультанты, которые готовы объяснить, что к чему.


И еще одно - vSphere vClient - программа для работы с гипервизорами vSphere ESX или vSphere vCenter. С помощью этой программы делают различные настройки систем виртуализации, и производят действия (например, создают ВМ).
Эту программу обычно ставят на персональные компьютеры системных администраторов.
Фактически - это основное окно, через которую можно "посмотреть" на виртуальную инфраструктуру VMware.


Иногда технические специалисты называют серверы ESX и vCenter просто vSphere, поэтому часто и возникает это недопонимание у новичков.


Итак, подытожу:
vSphere - это общее название платформы виртуализации компании VMware, состоящей из:

• обязательно - гипервизора ESX(i)
• желательно - vCenter
• и vClient для администрирования.

все остальное - дополнения и расширения.

Парольное бремя в ESXi 4.1

Шпаргалка.
На самом деле мне просто надоело в лабе на ESXi ставить длинные пароли. Но пригодится не только чтобы избавиться от политики длин паролей, но и на случай, если, наоборот, политику нужно усложнить.


Далее - все на свой страх и риск.

1. В ESXi 4.1 нужно включить режим "Tech Support"
2. Редактировать в файле "/etc/pam.d/system-auth" сроку:

password requisite /lib/security/$ISA/pam_passwdqc.so retry=3 min=8,8,8,7,6

Цифры в поле min означают минимальное количество символов пароля, в зависимости от количества примененных символьных классов при создании пароля. Классы это: маленькие латинские буквы, большие латинские буквы, цифры, все прочие символы.


Поле min имеет следующие параметры:

• Первое число - минимальное количество символов в пароле, если использовался только один класс: например, только маленькие буквы, или только цифры. По-умолчанию, в таком пароле должно быть не менее 8 символов.
  password
• Второе число - минимальное количество символов в пароле, если использовались два разных класса: например, маленькие и большие буквы. По-умолчанию, в таком пароле должно быть не менее 8 символов.
  PaSSword
• Третье число. По-умолчанию, в таком пароле должно быть не менее 8 символов.
• Четвертое число - минимальное количество символов в пароле, если использовались три разных класса: например, маленькие буквы, большие буквы и цифры. По-умолчанию, в таком пароле должно быть не менее 7 символов.
  Pa55Wrd
• Пятое число - минимальное количество символов в пароле, если использовались все четыре класса. По-умолчанию, в таком пароле должно быть не менее 6 символов.
  P@5Wrd

Четыре правила:

1. Изменения в политике паролей сразу после сохранения файла применяются ко всем новым паролям. Ни перегружать ESX, ни перезапускать никакие сервисы не надо.
2. Первый и последний символы пароля не идут в зачет, при подсчете количества классов. Т.е. пароли: Password, Password1 - должны считаться, как пароли содержащие символы только одного класса.
   Тогда как: PassWord - два класса, а pAssw0rd - три.
   
3. Числа в параметры min не могут повышаться от левого значения к правому значению. Значение вида: min=8,9,8,6,7 - создавать нельзя, чревато получением ошибки:
   "User name or password has an invalid format" при создании новых паролей.
4. Кроме непосредственного изменения цифр в параметре min, можно просто добавить в конце этой строки: enforce=none
   В этом случае политика длин паролей не применяется вообще.

Вот вам быстрое видео (быстрое - в различных смыслах :-) ):


P.S. В ESXi 4.0 файл звать "/etc/pam.d/common-password"

Elastic Sky X

Как-то странно, уже так давно (с VI3.5) сосуществуют ESXi и ESX, а люди до сих пор не понимают между ними разницы.
И часто считают, что ESXi - это только бесплатный гипервизор. В этом заблуждении  виновата сама VMware, долгое время называя бесплатный продукт "ESXi Free". И хотя не так давно VMware попыталась поправить это недоразумение, переименовав бесплатный продукт в VMware vSphere Hypervisor (ESXi), но это мало что изменило: многие обращают внимание на слово ESXi и продолжают думать, что ESXi = бесплатный.


Итак,

ESXi ≠ БЕСПЛАТНО

Все дело в сервис-консоли: она в ESX есть, а в ESXi ее почти нет (есть сильно сокращенная, и визуально проявляющаяся в виде консольной менюшки с настройками и вэб-интерфейсом).
Консоль ESX видна при загрузки в виде коммандной строки, к ней можно подключиться через SSH и т.д. и т.п.
Конечно, немного утрированно.

Таким образом ESX и ESXi - суть одно и то же - гипервизор и все. ESX - "толстый гипервизор", ESXi - "тонкий гипервизор".
Дальше все решают лицензии под общим названием vSphere. Грубо говоря, эти лицензии открывают дополнительный функционал, который часто реализуется благодаря наличию vCenter. Отмечу, что без vCentra не будут работать vMotion, DRS, DPM и многие прочие. А High Availability (HA), Fault Tolerance, Distributed Network Switch работают без vCenter - т.е. перезапуск виртуальных машин ВМ происходит, но включение и настройка требует наличия vCenter. И, соответственно, подобный функционал лицензируется централизованно через vCenter.

Эти лицензии одинаково подходят и к толстому и к тонкому гипервизорам, т.е. этот дополнительный функционал откроется и там, и там, и никакие плагины при этом не устанавливаются - все уже есть в ESX и ESXi. Так сделала VMware.


Еще программы третьих фирм (т.е. всех других производителей ПО, кроме самой VMware) могут устанавливать своих программных агентов внутрь консоли ESX. И раз такой консоли нет в ESXi, то соответственно и агенты этих третьих фирм в ESXi работать не будут.

Поэтому, третьи фирмы часто пишут "поддержка ESXi". Обратите внимание! Это не обязательно поддержка бесплатного ESXi - это означает только что поддерживается работа без требования установки какого-либо дополнительного программного агента в сервисную консоль!


А бесплатная лицензия работает только на ESXi. Это понятно: чтоб никто агентов не поставил в консоль и не сделал самописный HA, DRS и т.п. :)



Итак, уяснили в чем разница ESX и ESXi?
Точно уяснили?

Так вот, можете забыть :) Скоро не будет вообще ESX, и останется только тонкий гипервизор ESXi. :D

iESX - гипервизор для iPad

Дефрагментация дисков ESX

Важное замечание. Статью писал несколько лет назад. Потому стоит учесть, что она касается VI3. В vSphere есть технология CBT (changed bloacks tracking), которая очень помогает для быстрого резервного копирования. В этом случае дефрагментация только ухудшит работу. Точно также дефрагментация отрицательно будет влиять на тонкие диски.
В любом случае, дефрагментация внутри ВМ не даст приращения в скорости, поскольку доступ к всему тому LUN, при наличии большого количества файлов дисков ВМ, доступ будет не последовательный, а случайный.
Рекомендация одна: выберийте быстрые массивы для файлов ВМ.






Попалась мне статья про дефрагментацию дисков ESX. Так, короткая заметка на английском. Есть несколько интересных замечаний. Почему бы мне ее не пересказать?


Стоит разбить тему на две части: дефрагментация информации на диске внутри виртуальной машины (ВМ), и дефрагментация самих дисков ВМ в разделе VMFS (файловая система для виртуальных машин).


По первому вопросу: да, стоит. Сильно фрагментированный диск будет тормозить дисковую подсистему ВМ.
Но, нужно учитывать следующее:
1. Дефрагментация сама по себе дает интенсивный ввод-вывод на диски, а значит будет влиять на всю дисковую подсистему, что затронет все ВМ на данной партиции, включая запущенные на других ESX-серверах. И самое главное: не дефрагментируйте все ВМ скопом! Хотя... есть неплохой шанс проверить ваш SAN на прочность ;)
Короче, выбирайте время для дефрагментации, и запускайте дефрагментацию по очереди.

2. А вот это серьезней, и менее очевидный риф: Не дефрагментируйте ВМ с активными snapshot'ами! Во-первых, ваш файл дисковой разницы будет очень быстро пухнуть - так как много изменений происходит внутри виртуального диска. А, во-вторых, дисковая подсистема для всех ваших ВМ в данной партиции VMFS будет жутко тормозить, потому как snapshot начнет расти 16МБ блоками, а каждое изменение в размере файла на VMFS приводит к локированию всей VMFS-партиции.
От себя добавлю, выход есть: вначале дефрагментация, потом snapshot.


Что касается второй части - дефрагментации файлов ВМ на VMFS-партиции, мне понравилась в той статье фраза:
  "Ответим на этот вопрос: нет, по двум причинам. Во-первых, не существует механизма, ни встроенного, ни разработанного кем-то еще, который бы позволил это осуществить"
Отличное замечание, не правда ли? :) Вам вторая причина еще нужна?
  "Вторая причина в том, что хост в реальности и не фрагментирует данные, ввиду принципа создания и работы виртуальных дисков на VMFS"
Ага, мне второе замечание тоже понравилось. :) Причины две: нет ни возможности, ни надобности.


А далее статья рассказывается сам принцип создания дисков ВМ. На самом деле данные все-таки могут фрагментироваться, но не так, как это происходит с файлами в обычных ОСах. Заметим, что в отличие от обычных операционнок, здесь складывается противоположная ситуация: хранятся, по большей части, огромные файлы и в относительно небольшом количестве.
Если вы создаете обычный ("толстый") диск ВМ, или копируете с помощью утилиты vmkfstools, то виртуальный диск будет создан максимально большим куском, как правило, единым блоком, а затем уже будет наполнятся данными в случае копирования.
Фрагментация может произойти, если был создан так называемый "thin" диск, который будет расти по мере необходимости нового пространства, или если вы ошибочно копируете диск другой ВМ с помощью SCP (пользуйтесь vmkfstools!).
Также фрагментация происходит, когда вы создаете и удаляете snapshotы, и при автоматическом создании/удалении разных сопутствующих мелких файлов ВМ: логи, свопы и слепки памяти и т.п.

Таким образом, возможна ситуация, когда при очередном создании нового виртуального диска система не сможет выделить под него единый блок. Но в таком случае, просто будут создано некоторое небольшое количество все равно больших блоков. При том блоков настолько больших, что фрагментация будет настолько мала, что ей можно просто пренебречь.
Так что на этот счет просто не парьтесь! ;)