При установке ESXi на железо не из списка официально поддерживаемого часто сталкиваешься с отсутствием поддержки разных набортных контроллеров. В моем случае им стал контроллер сетевой платы Intel 82579LM. Проблема распространенная и сообществом давно решенная: драйвер для ESXi существует, и даже не один.
Какое-то время на этапе тестов пользовался драйвером от Chilly (находил его тут). Сам автор указывал на раннюю версию и возможные баги. После нашел версию драйвера от Aoyama, которую и использую сейчас.
Отдельной поддерживаемой сетевой карты не имею, а без сетевых карт ESXi не поставится, потому требовалось вшивать поддержку 82579LM в установочный образ гипервизора. Сделать это можно вручную, но удобнее использовать ESXi-Customizer.
Затем создал из модифицированного образа загрузочную флешку и столкнулся с очередной проблемой - установка вываливалась с ошибкой "недостаточно ресурсов" на этапе распаковки архива vmware-tools. Оказалось, причина в программе создания этой флешки. Первоначально использовал UltraISO довольно старой версии, причем никаких ошибок в процессе не наблюдалось. При переходе на UNetbootin, проблема исчезла. Просто странный и непонятный глюк. Глубоко копать не стал.
После установки ESXi успешно стартовал, сетевая карта определяется и работает без проблем.
Перешитый sata-контроллер Dell был успешно проброшен. На нем трудятся 6 дисков, собранных в 2 пула RAIDZ1 средствами виртуальной машины. Для проброса доступен еще ряд набортных контроллеров:
Встроенные датчики не поддерживаются: мониторинг температуры компонентов, напряжений, питания, скоростей вентиляторов отсутствует.
Локальное хранилище было решено посадить на небольшой SSD. С него будет стартовать небольшое количество избранных виртуалок (nas, vcenter, возможно что-то еще). Тестовые машины будут сидеть в хранилище, созданном средствами машины nas, некоторые из которых вполне могут потом мигрировать в рабочую среду с thin provisioning.
ESXi не поддерживате TRIM для vmfs, потому был выбран доступный SSD с хорошим garbage collection.
Для работы ESXi требует место хранения свопа, логов и другой служебной информации - scratch. Обычно при установке или при первом запуске создается необходимая структура папок/файлов на доступном хранилище. Если такового нет (в моем случае изначально гипервизор ставился на систему без доступных дисков), то создается ram-диск, где все это добро и живет. Так как создается достаточно небольшое по размеру пространство, то возможны проблемы при полном его заполнении, да и пространство не переживет ребута хоста, и возможно необходимые логи будут недоступны. Об отсутствии надежного scratch сразу же сигнализирует клиент сферы назойливым восклицательным знаком на хосте и предупреждением: "System logs are stored on nonpersistent storage".
После установки SSD и форматирования его в vmfs нужно было просто вручную перенести на него scratch. Для этого создал встроенным менеджером директорию .locker, затем в Software|Advanced Settings поменял параметр ScratchConfig.ConfiguredScratchLocation на соответствующий моему /vmfs/volumes/<Имя сторы>/.locker. После ребута хоста scratch переехал и надоедливый алерт пропал.
После этого настройка гипервизора была закончена, но возникла проблема, которую так и не смог решить до сих пор: хост нельзя увести в shutdown, то есть полностью выключить. Сразу после этого он включается обратно. Не успел поймать тот момент, когда эта проблема возникла. Никаких подозрительных ошибок в логах ESXi не нашел, пробовал садить сервер мимо UPS, проверял настройки, перешивал BIOS - не помогло. Наверное стоит попробовать поставить на тестовый диск какую-нибудь ОС, да проверить, сможет ли она выключить сервер, но мне лень обратно все разбирать, перетыкать и переставлять. Возможны проблемы железного характера, может дело в блоке питания. Проверю как только переборю лень.
Update: обновление ESXi до новой версии и новая установка на отдельную флешку проблему не решают - хост по прежнему перезагружается вместо выключения. Загруженный с отдельного винта сервер 2008R2 ту же самую систему выключает нормально. Будем искать...
Эта проблема доставит неудобства тем, что нельзя будет выключать сервер по сигналу низкого заряда UPS, но пока это не критично - от коротких сбоев питания он спасает, а длительные редки. Да и гасить машины, оставляя работать сам хост все же можно, потому за сохранность данных беспокоюсь меньше.
Следующим этапом будет установка виртуальной машины NAS.
ESXi не поддерживате TRIM для vmfs, потому был выбран доступный SSD с хорошим garbage collection.
Для работы ESXi требует место хранения свопа, логов и другой служебной информации - scratch. Обычно при установке или при первом запуске создается необходимая структура папок/файлов на доступном хранилище. Если такового нет (в моем случае изначально гипервизор ставился на систему без доступных дисков), то создается ram-диск, где все это добро и живет. Так как создается достаточно небольшое по размеру пространство, то возможны проблемы при полном его заполнении, да и пространство не переживет ребута хоста, и возможно необходимые логи будут недоступны. Об отсутствии надежного scratch сразу же сигнализирует клиент сферы назойливым восклицательным знаком на хосте и предупреждением: "System logs are stored on nonpersistent storage".
После установки SSD и форматирования его в vmfs нужно было просто вручную перенести на него scratch. Для этого создал встроенным менеджером директорию .locker, затем в Software|Advanced Settings поменял параметр ScratchConfig.ConfiguredScratchLocation на соответствующий моему /vmfs/volumes/<Имя сторы>/.locker. После ребута хоста scratch переехал и надоедливый алерт пропал.
После этого настройка гипервизора была закончена, но возникла проблема, которую так и не смог решить до сих пор: хост нельзя увести в shutdown, то есть полностью выключить. Сразу после этого он включается обратно. Не успел поймать тот момент, когда эта проблема возникла. Никаких подозрительных ошибок в логах ESXi не нашел, пробовал садить сервер мимо UPS, проверял настройки, перешивал BIOS - не помогло. Наверное стоит попробовать поставить на тестовый диск какую-нибудь ОС, да проверить, сможет ли она выключить сервер, но мне лень обратно все разбирать, перетыкать и переставлять. Возможны проблемы железного характера, может дело в блоке питания. Проверю как только переборю лень.
Update: обновление ESXi до новой версии и новая установка на отдельную флешку проблему не решают - хост по прежнему перезагружается вместо выключения. Загруженный с отдельного винта сервер 2008R2 ту же самую систему выключает нормально. Будем искать...
Эта проблема доставит неудобства тем, что нельзя будет выключать сервер по сигналу низкого заряда UPS, но пока это не критично - от коротких сбоев питания он спасает, а длительные редки. Да и гасить машины, оставляя работать сам хост все же можно, потому за сохранность данных беспокоюсь меньше.
Следующим этапом будет установка виртуальной машины NAS.
Комментариев нет:
Отправить комментарий