Неразборчивое о виртуальном

Записи с меткой kb

Как известно, после выхода новой vSphere 5, который вроде бы ожидается в сентябре, лицензии на 4.x напрямую купить уже не получится.

В связи с тем, что не каждый админ отважится сразу заливать на "боевые" серевера свежий релиз, потребность в ключах для 4.x будет сохраняться ещё некоторое время.

Приведу цитаты из партнёрского FAQ по поводу приобретения лицензий для инфраструктуры предыдущих версий. Почему-то в публичной версии такого документа упоминаний об этом я не нашёл.

Q: Can I downgrade from vSphere 5 to a previous version?

A: Yes, vSphere licenses can be downgraded to vSphere 4.x or VI 3.5 licenses. <...> When downgrading, you agree to discontinue use of the vSphere 5 license keys.

Q: Can I upgrade licenses on which I previously performed a version downgrade back to vSphere 5?

A: Yes. When performing a version upgrade, the licensing model for that version applies (e.g., CPU with vRAM entitlement
for vSphere 5), and you must agree to discontinue use of the vSphere 4.x or VI 3 licenses used for the version upgrade.

UPD: статья KB про лицензирование.

Накопилось некоторое количество ссылок и заметок на тему работы с VMware Capacity Planner.

1. Для установки Capacity Planner Data Collector на систему с Win2k8 необходимо наличие в системе .NET 3.5+. Банально, но почему-то нигде в документации я этого требования не нашёл. Без .NET прекрасно ставится, но при запуске сыпет невразумительные ошибки.

2. Troubleshooting access rights, policies, and permissions preventing data collection — крайне полезный список, что и как следует проверять, если к Windows-системам не получается достучаться коллектором.

3. Вариант, что делать, если всё из вышеназванной KB дало только частично положительный эффект:

В правах доступа ветки реестра HKLM\Software\Microsoft\Windows NT\CurrentVersion\Perflib\ на проблемной машине для Local Service дать не Read, a Full Control.

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

4. Оказывается, что для генерируемых отчётов не получается использовать собственные сценарии консолидации. Судя по дате сообщения, проблеме почти 2 года, но и сейчас у меня получилось только подправить два стандартных сценария под свои нужды.

5. Статья в KB от том, что нужно настраивать для получения "красивой" цифры результирующего процента консолидации.

Обновление тестового кластера прошло неудачно :(

Мигрировал VC 4.0, win 2003 R2 32bit на VC 4.1, win 2008 R2 (SQL и там и там - локальный Express). Hostname и IP наследовались.

Datamigration tool сначала отказывалась видеть прежний SQL - помогла kb 1024490, последний пункт. После этого backup.bat и install.bat на обоих машинах браво отрапортовали что всё sucessfull, но после подключения клиентом, в inventory было пусто. При этом только что установленный vCenter ругался на окончание своего Evaluation period. В логах тоже ничего криминального не было найдено.

Далее обновил два ESXi c 4.0 до 4.1:

C:\Program files\VMware\VMware vSphere CLI\bin>vihostupdate.pl --server 10.10.10.104 --install --bundle c:\TEMP\upgrade-from-ESXi4.0-to-4.1.0-0.0.260247-release.zip

Сразу после обновления оба хоста добавил в vCenter. Спустя какое-то время хост1 начал сыпать варнингами, а потом вообще перестал пинговаться. Разбираясь локально в чём дело, выяснил что после перезагрузки перепутались местами(!) и IP адресами vmknic'и :) Управляющий vmk0 поменялся портгруппой (и виртуальным свичём) с vmk1 (который был для NFS). NFS трафик у меня ходит в отдельной физической сети.

В довершении всего, через локальную консоль (ту. что на жёлтом фоне) не получалось не переопределить управляющий vmk, ни сменить ему IP. После подтверждения изменений всё оставалось прежним. Пришлось править всё руками в TechSupport Mode.

Источники:

vSphere 4.1 upgrade pre-installation requirements and considerations

Migrating an existing vCenter Server database to 4.1 using the Data Migration Tool

vSphere Upgrade Guide

Upgrading ESX 4.0 to ESX 4.1(video: UM, esxupdate, vihostupdate)

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

Но даже по сравнению с предыдущим переездом с 3.5 на 4.0, количество найденного садового инвентаря несколько огорчает.

UPD: Как выяснилось, это не я налажал -- это известная ошибка, связанная с тем что datamigration tool некорректно обрабатывает локальный SQL Express. Подробности в kb.

Начиная с версии ESX(i) 4.0, изменилась процедура маскирования LUN'ов на уровне гипрвизора. Вместо прописывания адресов LUN в Advance Settings -> Disk -> Disk.MaskLUNs, в vSphere для все путей переопределятся плагин PSA на специальный - MASK_PATH.

Для начала удаляем из инвентори все объекты, связанные со скрываемым LUN'ом. Далее:

1. esxcfg-scsidevs -l Первой строчкой описания каждого устройства идёт LUN_ID, запоминаем его для скрываемого LUN'а

2. esxcfg-mpath -L | grep <LUN_ID> Находим все пути для этого раздела. Запоминаем адрес ввиде: vmhba#:C#:T#:L#, в моём случае vmhba2:C0:T2:L0. При желание, это можно сразу посмотреть в vSphere Client.

3. esxcli corestorage claimrule add --rule 123 -t location -A vmhba2 -C 0 -T 2 -L 0 -P MASK_PATH Добавляем правило в конфигурационных файл. Выбираем любой незанятый номер правила, но обязательно из диапазона 101--200.

4. esxcli corestorage claimrule load Загружаем созданное правило в список активных

5. esxcli corestorage claimrule list Проверяем, что в списке есть два одинаковых правила с выбранным номером с параметрами file и runtime.

6. esxcli corestorage claiming reclaim -d <LUN_ID> Переопределяем текущие правила для путей раздела на только что созданные.

Всё. Считаем до 10 и LUN больше недоступен для добавления datastor'а. Все пути, помеченные MASK_PATH, переходят в состояние Dead.

По статье kb.

Для чего это нужно? Например, для процедуры корректного удаления LUN'а "на лету":

Удаляем всё с LUN'а-> маскируем его-> отменяем презентацию LUN'а хосту средствами стораджа-> удаляем правила маскирования.