Записки о виртуализации и о жизни
Если у вас не получает подключиться к консоли виртуальной машины в vSphere 5.5 Web Client, то проверьте разрешен ли у порт 7331 в брандмауэре. Установщик забывает разрешить доступ к данному порту, поэтому, в случае потребности, создайте правило вручную.
В случае если вместо консоли получаете на просмотр папку /console/, то мне помогала перезагрузка всего сервера с vCenter, где зарыта собака, я не нашел.
С виртуализацией я плотно общаюсь с середины 2007 года. Начинал я общение еще с VMware Virtual Infrastructure 3.5, после которой и появилось модное словцо “vSphere”.
Иногда мне приходится отвечать на вопрос, в чем различие разных версий vSphere. Попробую дать ответ ниже и описать появление функционала в различных версиях…
Если можете поведать еще о каких-то интересных фичах, не вошедших в этот обзор – пишите в комментариях со ссылками – обязательно добавлю…
В VMware ESXi5.5 используется новая архитектура драйверов. Почитать о ней можно в блоге William’a Lam’a: ESXi 5.5 introduces a new Native Device Driver Architecture Part 1(по-русски), Part 2.
К сожалению, у меня возникла серьёзная проблема с подключением к сети хранения данных – LUN’ы при загрузке ESXi не подключались, а в загруженном состоянии требовалось минут 20-30 для отображения всех дисков и хранилищ.
Подозрения пали на драйвер для HBA QLogic в новой архитектуре – qlnativefc.
Для решения проблемы пришлось выключить данный модуль командой в CLI:
|
1 |
esxcli system module set --enabled=false --module=qlnativefc |
Наш с Андреем “тёзка” 😉 – Андрей Коновалов в октябре 2013 года написал статью “Включение Virtual Flash Read Cache в VMware vSphere 5.5”, в которой подробно описал как включать и что делать если SSD не определился. В качестве своего опыта расскажу также о борьбе с неопределением типа SSD-накопителя.
Лезвие IBM HS22V имеет SAS-контроллер на чипсете LSI 1064E, который собирает простые RAID в виде зеркала либо чересполосицы.
Изначально ESXi 5.1 стоял на зеркале из 2 SSD(вот она бессмысленная трата столь ценного ресурса), что и приводило к проблемам с проверкой на тип носителя.
ESXi 5.5 решили установить на USB-flash, а RAID разобрать. Контроллеры LSI при разборке RAID 1 на дисках ничего не меняют – в результате получилось 2 идентичных диска с ESXi 5.1 и установка ESXi 5.5 прекратилась с розово-фиолетовым экраном и выпадением консоль vmdebug, ранее ни разу не виденную мной. Ошибка на экране гласила что-то в духе: “Two filesystems with the same UUID have been detected. Make sure you do not have two ESXi installations“. Для вариантов решения советую почитать “ESXi host displays an error and fails to boot when two ESXi installations are on the same system“.
В связи с этим RAID пришлось собрать снова, что привело к переинициализации дисков и очистке файловых систем на них, затем снова разобрать RAID для представления дисков серверу “напрямую”.
После перезагрузки ESXi 5.5 встал на ура, диски определились как SSD.
P.S. Хотел сначал написать про Virtual Flash Read Cache, а писать-то нечего – как настраивать написано везде, описание занимает 2 скриншота, и, вроде, эта штука работает… Даже новые счётчики отображает в C# клиенте…
Полтора года назад я писал о том, что IBM DS3500/DCS3700 приобретают поддержку VAAI и ALUA. Сейчас хранилище данного типа у меня используется и время от времени ругается на предоставление LUN по непредпочитаемому пути. Как оказалось, ALUA не работает – Storage Array Type=VMW_SATP_LSI:
Решение довольно простое – в DS Storage Manager необходимо сменить операционную систему подключаемого к хранилищу сервера с VMWARE на VMWareTPGSALUA:
После перезагрузки хоста политика Storage Array Type=VMW_SATP_ALUA:
Внезапно, УЦ “Микроинформ” проводит бесплатный актуальный вебинар о переходе на VMware vSphere 5.5.
Дата проведения: 30 января 2014 г.
Начало вебинара: 16:00 МСК.
Продолжительность вебинара: 1,5 часа.
Не прошло и года, как увидел свет третий релиз системы управления VMware vSphere 5.5. Список решенных проблем поражает, впрочем, оставшихся багов не меньше.
P.S. Пожалуй, посижу пока на vCenter 5.1a – чей-то не охота до Нового Года развлекаться с этим щастьем…
Вот и моя очередь настала написать о полученных с SSO граблях. Ранее об этом уже писал Виктор.
Итак, на исходной – перестал работать доменный вход в vCenter 5.1. Попытка узнать, насколько глубока кроличья нора, привела меня под кат 🙂
Сегодня о “худшей практике” одной настройки виртуальной машины.
Некоторое время назад обнаружились серверы с большим уровнем IOPS – в районе 1000-1500 операций. Экспресс-диагностика не дала результата, а так как размер дисков машин был очень небольшим, то они были перемещены на локальные SSD, что сняло остроту проблемы.
Сейчас же обнаружились проблемы с терминальными серверами – довольно сильные лаги при большом количестве подключений. Анализ системы показал довольно классическую проблему – наличие baloon. Наличие “пузыря” в памяти насторожило, так как на хосте свободной памяти было с избытком. Ларчик открылся просто при 3 ГБ ОЗУ виртуальной машины стояла волшебная труодминская настройка memory limit 2 ГБ. К пущей радости, история умалчивает кто был этим тру одмином.
После такого открытия я запустил RVTools и проинспектировал все виртуальные машины на наличие лимитов памяти, ну, и на “пузыри” заодно.
Тут-то и всплыли виртуалки с большими IOPS, так как настройки на них были примерно следующие ОЗУ – 1,5 ГБ, лимит – 256 МБ. На одной из машины при ОЗУ 3 ГБ, лимит был 512 МБ, а размер “пузыря” 2 ГБ.
Для чего понадобилось выставлять лимиты остаётся загадкой. Поснимал все лимиты на память, так как для моей конфигурации данный функционал не имеет смысла.
Не успела выйти VMware vSphere 5.5, как проблемы снова с нами 🙂
Набивший ранее оскомину VMware SSO v1, переписанный с нуля компанией VMware, по прежнему клюет мозг. Согласно информации из официального блога, SSO v2 не “видит” группы, которые вложены в локальные группы vCenter Server.
Пока решение очень простое – добавлять такие группы руками и ждать обновления.