знать бы раньше, что всё так получится!

Переставлял блэйд-сервера HP из корзины где Virtual Connect, который назначал WWN серверам, в корзину, где тоже Virtual Connect, но используются заводские WWN
Сервера с HBA QLogic после перестановки получили заводские WWN, как и было положено. А сервера с адаптерами Emulex LPe1205 (всего штук 10 серверов) сохранили WWN назначенные в предыдущей корзине, хотя в Onboard Administrator'е отображались заводские
Обновление и откат прошивки HBA результата не дали

Гугл рассказал, что адаптеры Emulex имеют аж 3 места, где хранятся WWN:
volatile memory - то что используетс я в работе в настоящий момент
non-volatile memory - энергонезависимая память, где хранятся WWN которые будут использоваться при следующей загрузке
прошитые на заводе значения

Так вот почему-то некоторые адаптеры (как говорит поддержка, зависит чуть ли не от партии и может проявляться или не проявляться для одной и той же модели), попадая в корзину с Virtual Connect (или другими свитчами, которые не умеют менять WWN на любых адаптерах HP, например Brocade), который использует заводские значения, не перезаписывают заводские WWN в non-volatile memory

После переписки с поддержкой HP (которая надо заметить признала глюк и пообещала что L3 работает над проблемой) предложила workaround:
однако, у Emulex есть утилита OneCommand Manager, которая позволяет, помимо всего прочего, вручную записывать в non-volatile memory произвольные значения (в том числе есть кнопочка Get Factory Default WWNs)

Утилита поставляется в виде отдельной софтины для Windows, Linux, Mac, Solaris, FreeBSD, и плагина для vCenter
При этом, в OneCommand Manager для Windows можно добавлять и другие сервера, в том числе ESXi (так что для управления гипервизорами плагин для vCenter не обязателен, что лично мне было приятно. Не люблю ставить лишние плагины ради одноразового использования)
Чтобы управлять серверами с ESXi (в том числе из плагина для vCenter) нужно установить Emulex CIM Provider (поставляется в виде bundle, можно ставить через Update Manager)

Выглядит всё примерно так:
Выбираем конкретный FC порт, вкладка Maintenance и кнопка Change WWN



Дальше нажимаем Get Factory Default WWN


Ребут и готово


Связка с ESXi довольно нестабильная. Хосты регулярно пропадают из консоли и появляются после перезагрузки, а иногда просто так со временем (толи CIM Provider не отличается надежностью, толи ESXi любит, чтобы им управляли из vCenter). Но тем не менее схема работает

Плагин для vCenter и CIM Provider:
http://www.emulex.com/downloads/em…

Там же можно выбрать и для другие ОС.

Забавный глюк обнаружился на днях:
Если имя компьютера, на котором запущен Worker совпадает с именем пользователя от которого запускается конвертация (не важно P2V или из файлов в vSphere) получаем ошибку "A specified parameter was not correct: info.owner"
Притом не обязательно чтобы пользователь был локальным. Например пользователь pupkin.sub.domain.ru запускающий worker на компьютере pupkin.top.domain.com получит ошибку
Не имеет значение FQDN пользователя и компьютера, важны именно логин пользователя и логин компа

Пробовал на 5.0, потом переименовал комп, так что насчет старших версий не уверен :)

Допустим, поменяли мы IP или hostname сервера SRM. Или же просто хотим чтобы vCenter обращался к серверу SRM по FQDN, а не по IP, как было указано при установке SRM. В общем, хотим чтобы изменился вот этот параметр

Открываем файл:
C:\Program Files\VMware\VMware vCenter Site Recovery Manager\config\extension.xml
Делаем "найти и заменить" то что есть, на то что нужно. Сохраняем

Запускаем перерегистрацию расширения с помощью утилиты srm-config с ключем -cmd updateext
> cd C:\Program Files\VMware\VMware vCenter Site Recovery Manager\bin
> srm-config.exe -cmd updateext -cfg ../config/vmware-dr.xml -extcfg ../config/extension.xml

Ждем...
Когда всё выполнится, перезапускаем службу VMware vCenter Site Recovery Manager Server
После такого может отвалиться от публичной сети vCenter защищенный Heartbeat'ом (в 2 из 2 случаем так и было), channel остается. Лечится сменой активной ноды (switchover) и ребутом потерявшегося сервера. Причины не ясны :)

Ну и в конце, Configure Connection

Relaxed co-scheduling
Процессоры одной ВМ ожидающие исполнения (находятся в очереди ready) не обязательно должны попадать на процессор все вместе. Если исполняются не все vCPU одной ВМ, то гипервизор считает разницу в прогрессе ("skew") между vCPU с наибольшим и наименьшем прогрессом. Если skew превышает определенное значение (несколько миллисекунд), то vCPU с наибольшим прогрессом снимается с процессора (co-stop) то тех пор пока отстающий vCPU не начнет исполняться, после чего остановленный vCPU сможет вернуться на процессор (co-start), либо в очередь ready, если свободных процессоров нет
Skew считается между vCPU исполняющимися на процессоре и vCPU, которые не находятся ни на процессоре ни в очереди IDLE

NUMA
  Если ВМ работает на сервере с NUMA архитектурой, то для машины задается домашняя NUMA нода. Все vCPU располагаются в одной ноде и память по возможности выделяется из домашней ноды. Если количество vCPU машины превышает размер NUMA ноды сервера ("wide VM"), то для такой машины создается несколько NUMA клиентов и для каждого клиента задается домашняя NUMA нода. При этом выделение памяти чередуется между всеми домашними нодами
 Начиная с vSphere 5.0, для машин поддерживающих vNUMA, память для NUMA клиента выделяется из домашней ноды

vNUMA
vNUMA - проброс информации о физической NUMA архитектуре в гостевую ОС
Работает на ВМ начиная с 8-й версии виртуального железа и старше. По умолчанию включена на ВМ с количеством ядер больше 8 (9 и больше).
Данные параметр можно изменить добавив в файл конфигурации ВМ параметр
numa.vcpu.min.

Для ВМ с включенной vNUMA количество ядер на NUMA клиента определяется:
- Если параметр cores per socket = 1 (количество vCPU задается количеством сокетов), то vNUMA топология формируется автоматически. Если количество vCPU меньше или равно размеру NUMA ноды, то создается 1 NUMA клиент. Если больше, то размер ноды подбирается исходя из размера физической NUMA ноды. Например ВМ 8 sockets, 1 cores per socket запускается на сервере 2х6CPU, то машина будет состоять из 2 NUMA узлов по 3 ядра.

- Если cores per socket отлично от 1, то размер vNUMA ноды будет равен размеру виртуального сокета
В данном случае, если размер vNUMA ноды не превышает размер физической, то размер физического NUMA клиента ВМ будет равен размеру виртуальной ноды. Если превышает, то возможны варианты. См. доку по шедулеру

CCI (Command Control Interface) - интерфейс управления некоторыми функциями массива с помощью cli. Включает в себя утилиту HORCM и command device (лун маленького размера, достаточно 100мб, который используется для отправки команд на массив и получения некоторой информации от массива)
Используется для управления (именно управления: разорвать, синхронизировать, удалить. Начальную настройку необходимо делать через Storage Navigator) репликациями, снэпшотами и для сбора performance данных (например Tuning Manager использует command device для получения статистики)

- Файл horcm.conf хранится в c:\windows
- Называется в зависимости от номера инстанса: horcm0.conf horcm1.conf соответственно для 0 и 1 инстанса
- Формат файла:
test2 192.168.20.1 horcm0



Подробнее формат файла:
HORCM_MON:
- 192.168.10.1 - ip инстанса
- horcm1 - сервис описанный в c:\windows\system32\drivers\etc\services
Вместо названия horcm1 можно указать порт. Например udp\60000 (не обязательно такой порт, главное чтобы отличались для инстансов)
- 1000 и 3000 таймауты. Лучше оставить как есть


HORCM_CMD
\\.\CMD - берется первый попавшийся девайс который является command device
\\.\PHYSICALDRIVE2 - указане номера диска, как его видит система
\\.\CMD-55566 - с указанием серийника массива
\\.\CMD-55566-031 - c указанием серийника массива и номера ldev (переведенного из hex в dec, в данном случае 00:00:1F)
\\.\IPCMD-10.10.1.1 - с указанием IP адреса SVP. Подходит для VSP и HP P9500. Если помрёт SVP, нельзя будет рулить репликациями

Для command device, проброшенного в виртуалку, подходят только первые два варианта и IPCMD (видимо из-за того что RDM не поддерживает передачу scsi команды REPORT LUN, что мешает увидеть данные луна)

HORCM_LDEV
формат такой:
#dev_group        dev_name        Serial#   CU:LDEV(LDEV#)   MU#
dev_group - Имя группы девайсов. Описание понятное для админа. Объединяет в себе несколько девайсов, может использоваться как consistency group
dev_name - Имя конкретного девайса, опять же для понимания админа
Serial - серийник массива
CU:LDEV - номер CU и номер ldev (00:05, 01:2f и тд.)
MU - mirror unit. Имеет смысл для снэпшотов и ShadowImage (HP: BusinessCopy)

HORCM_INST
test1 - имя группы, для которой указан второй инстанс
horcm0 - аналогично horcm1 - сервис, описанный в файле services
192.168.20.1 - ip второго инстанса

Если парой необходимо управлять только с одного массива (например при использовании snapshot или ShadowImage) то необходимо запускать на управляющем сервере два инстанса HORCM (с разными номерами) и для каждого инстанса сделать свой файл horcm.conf c соответствующим номером.
В этом случае ip HORCM_MON и HORCM_INST будут совпадать, но порты должны использовать разные (ну или разные описанные службы в файле services)

Синтаксис
set HORCMINST=1 - установка инстанса по умолчанию. Чтобы для запуска и остановки не нужно было указывать номер
set HORCC_MRCF - по умолчанию работа с репликациями (вместо снэпшотов) в командах pairdisplay, pairsplit, pairresync

Бинарники лежат в папке \HORCM\etc
horcmstart 0 - запуск инстанса 0
horcmshutdown 0 - остановка инстанса 0
pairdisplay -g test1 - состояние всех пар в группе test1. -g обязательный параметр
pairdisplay -g test1 -d dev1 - состояние пары для пары dev1 в группе test1
-fcx отображает номер ldev в hex как на массиве (параметр -fx) и состояние копирования в %(-fc), либо отставание SVOL, если пара в состоянии PSUS
-ITC2 - отображает состояние репликационной пары (не отобразит снэпшоты) для инстанса 2
-ISI2 - опция: отображает состояние пары для снэпшота, инстанс 2
-ITC# и -ISI# используются так же для команд pairsplit и pairresync

Пример:
pairdisplay -g test1 -d dev2 -ITC0 -fcx
Состояние пары dev2 в группе test1, пара репликационная, итнстанс 0, ldev в hex и % копирования (либо оставание SVOL)

pairsplit -g test1 -d dev2 - разрыв пары dev2 группы test1, перевод пары в состояние PSUS/SSUS (либо для всей группы, если это consistency group)
pairsplit -g test1 - аналогично для всей группы

pairresync -g test1 -d dev2 - восстановление репликации. Не забываем -ITC и -ISI

Запуск в качестве службы Windows
1. Если инстанс отличный от 0, то копируем файл  C:\HORCM\Tool\HORCM0_run.txt, переименовываем в HORCM#_run.txt (# - номер инстанса)
2. Внутри файла исправляем строчку set HORCMINST=0 на нужный номер инстанса
3. Создаём службу:  C:\HORCM\tool\svcexe.exe /S=HORCM# "/A=C:\HORCM\tool\svcexe.exe" (# - номер инстанса)
4. Если служба запускается от имени SYSTEM, то в файл HORCM#_run.txt нужно добавить строку  set HORCM_EVERYCLI=1 после строки START: ,иначе не будут работать консольные команды. SRM при этом работает нормально
5. Локально может работать несколько служб, аналогично нескольким инстансам HORCM

Огреб в очередной раз в самый неподходящий момент проблему. И решил-таки докопаться до истины

При попытке мигрировать с хоста на хост VM с подключенным диском RDM можно наткнуться на ошибку
Virtual Disk "Hard Disk X" is a mapped direct-access LUN that is not acceptable

На первый взгляд всё может быть идентично - LUN id, Device id даже пути через которые этот LUN доступен
Однако, если не совпадает vml, прописанный в RDM файле с vml на хосте, на который пытаетесь смигрировать, то миграция будет невозможна
Сам vml id содержит и device id и LUN id (vml.0200xx0... - xx это LUN id в hex)
Посмотреть vml с которым лун подцеплен к машине можно в её свойствах


Чтобы узнать с каким vml на хосте виден девайс, в консоли пишем
esxcli storage core device list -d naa.60060...

В выводе команды последняя строчка
Other UIDs: vml.020000000060060e... это и есть тот самый vml id

Так вот этот самый Other UID формируется при подключении луна: при загрузке хоста, либо при презентации
Вроде бы все просто - отпрезентовать лун с неправильным LUN id и презентовать с правильным, но не всегда и не на всех массивах это банально (например если лун примаплен кластеру, то может не быть возможности отпрезентовать только один лун только от одного хоста)
Может получиться, что презентован лун был с одним номером, потом презентацию переделали по другим путям с другими LUN id. Так вот до перезагрузки vml останется старым и может казаться, что всё хорошо. Потом же, например, при массовом обновлении можем столкнуться с ситуацией когда машина не может мигрировать на уже обновленные хосты

Если мы все-таки измернулись и добавили пути с правильным LUN id и хостим, чтобы хост сформировал нужный нам vml, не обязательно ребутать хост, можно сделать mask path по всем путям и потом вернуть обратно. В этом случае хост увидит лун заново и сформирует новый vml id

Процедура такая:
1. Создаем claimrule для всех путей
esxcli storage core claimrule add -r 110 -t location -A vmhba0 -C 0 -T 1 -L 5 -P MASK_PATH
esxcli storage core claimrule add -r 111 -t location -A vmhba1 -C 0 -T 2 -L 5 -P MASK_PATH

2. Загружаем созданные правила
esxcli storage core claimrule load

3. Делаем reclaim для всех путей девайса (переопределяем какие плагины должны быть ассоциированы с путями)
esxcli storage core claiming reclaim -d naa.600600...

После этого девайс пропадет из списка
Теперь нужно вернуть как было

4. Удаляем созданные правила и применяем изменения
esxcli storage core claimrule remove -r 110
esxcli storage core claimrule remove -r 111
esxcli storage core claimrule load

5. Unclaim для скрытых путей (тут надо помнить какие -A -C -T и -L использовались, как посмотреть, если не записали не знаю)
esxcli storage core claiming unclaim -t location -A vmhba0 -C 0 -T 1 -L 5
esxcli storage core claiming unclaim -t location -A vmhba1 -C 0 -T 2 -L 5

Девайс вернулся назад. Делаем rescan all, либо в консоли
esxcli storage core claimrule run

KB:
mask path: http://kb.vmware.com/selfservice/m…
unmask path: http://kb.vmware.com/selfservice/m…
Проблема с миграцией машины с RDM: http://kb.vmware.com/selfservice/m…
Идентификаторы лунов: http://kb.vmware.com/selfservice/m…

Фабрика не соберется (статус порта будет E-Port segmented ... ) если:

1. ошибка: port xx, Incompatible, "Long distance fabric or Long distance port mode".
- Режимы LongDistance портов не совпадают (portcfglongdistance - LS или LD)
Посмотреть тип линка - portbuffershow

- Режимы LongDistance фабрик не совпадают.
Проверить configshow -pattern "fabric.ops." или configshow | grep fabric.ops. параметр fabric.ops.mode.longDistance:0
Правится командой configure на новом свитче
Данный параметр может не совпадать, если свитчи соединены длинным линком (portcfglongdistance - LS или LD)

2. Ошибка: port хх, Zone Conflict
Помимо отсутствия зонинга на подключаемом свитче возможно нужно сделать:
defzone --allaccess
cfgsave

Не забудь:
cfgdisable
cfgclear
cfgsave
switchdisable (на всякий случай)

Полезно: http://www.brocade.com/downloads/d…

Даже при отключенном перед обновлением Linked Mode бывает, что установщик находит следы Linked Mode и пытается его собрать после обновления. Это у него не получается из-за ошибки связанной с SSO (для корректной работы Linked Mode на 5.1 нужно чтобы сервера SSO обоих vCenter являлись членами одного логического объекта SSO - общий SSO сервер, либо пара серверов в режиме multisite. На втором сервере естественно никакого SSO еще нет, отсюда и ошибка). При этом установка завершается с ошибкой. Получаем ни 5.1 ни 5.0
Правда если запустить повторную установку, то всё проходит гладко, разве что еще раз спросит про лицензию, но обновится нормально. Даже роли и права никуда не денутся

Следы могут быть тут:
HKEY_LOCAL_MACHINE\SOFTWARE\VMware, Inc.\VMware VirtualCenter
Должно быть так:
GoupType = Single
LinkedMode = 0
PrimaryAdamServer - пусто

Если имеем пару серверов vCenter в Linked Mode, хотя бы один из которых защищен с помощью Heartbeat, и хотим их изолировать (например для обновления с 5.0 до 5.1), причем не важно запускаем изменение настроек с сервера который защищен Heartbeat или нет, то по умолчанию, скорее всего, получим вот такую ошибку:
Error 28040: setup cannot isolate vcenter server
И в логах jointool.txt видим запись
Operation "Isolate instance VMwareVCMSDS" failed: : Action: Prepare for Isolate Problem: Unable to reach a peer instance

Для изменения настроек Linked Mode должны быть остановлены службы
VMware VirtualCenter Management Webservices
VMware VirtualCenter Server
Однако, Heartbeat не понимает, что они остановлены по делу инсталятором и пытается тут же их перезапустить, что приводит к сбою установки. Если же согласиться с предложением форсировать отсоединение, можем получить мёртвый экземпляр VMwareVCMSDS и, как результат, не запускающуюся службу vpxd

Так что перед добавлением или изолированием, на серверах, защищенных vCenter Server Heartbeat, в настройках Heartbeat: Application -> Services меняем поведение данных служб при сбое на Log Warning

Можно более кошерный вариант:
Applications - Configure. Выбираем Unprotect services and stop monitoring...

Ну и включить после окончания (второй вариант повесит Warning пока защита не будет включена обратно)

http://kb.vmware.com/selfservice/m…

При удалении из Failover кластера диска, от которого зависят другие диски, либо если он зависит от других дисков, то удаляется вся цепочка зависимостей
Например Disk 3 зависит от Disk 2, а Disk 2 зависит от Disk 1, то при удалении из кластера Disk 2, удаляются все три
ХЗ это бага или фича, но я был в ах... удивлён от кривизны логики