У нас два одинаковых хоста (в смысле у них строго одинаковое железо и одинаковый софт VMware ESXi, 5.5.0, 1331820), они подключены к одним и тем же datastorage, свитчу. Конфигурацию делал одинаковую.
Все работает уже несколько лет. Никаких существенных изменений в хосты мы уже давно не вносим, только потихоньку создаем и уничтожаем VM.
Загрузка хостов по памяти и процессорам не выше 50%, обычно - существенно ниже.
Один из хостов уже в третий раз завис. Первый раз это было пару лет назад, второй - в ночь на 12-е марта, третий - в ночь на 19, то есть два последних зависания пришлись примерно на одно и то же время - 3 часа ночи, в ночь на воскресенье.
Картина зависания: на экране висит нормальная "серая" картинка, пинги не идут, VM все перестают работать.
Реагирует ли на нажатия клавиш, проверить не могу: KVM с новой Java работать отказывается, эту проблему придется решать отдельно.
После перезагрузки все стартует почти нормально (что ненормально - ниже), все штатно, VM, которые под Windows, сообщают: Предыдущее завершение работы системы в 2:59:30 на 19.03.2017 было неожиданным (на самом деле эта VM работала еще сколько-то секунд - в Security логе есть запись в 2:59:43.
Логи хоста и всех VM, работающих на нем (примерно 15 штук) перерыл - ничего особенного до прекращения работы в логах не обнаружил.
Вопрос 1: куда копать, что смотреть и как ловить?
Что было ненормально: в эвентах (уже в процессе рестарта) появляется сообщение о проблемах с сетевым адаптером "network uplink redundancy lost"
У меня есть виртуальный свитч с двумя адаптерами, роутинг по source MAC. Однако хост показывает, что все адаптеры работают нормально.
В логах хоста на эту тему я ничего не нашел, но зато нашел много сообщений о том, что iSCSI соединения (3 штуки) многократно разъединялись и заново подключались.
У меня, действительно, три VM используют iSCSI диски, но на этом хосте работает только одна из трех VM, и она работает нормально, т.е., iSCSI диск у нее в порядке.
На двух других тоже все в порядке с iSCSI.
Вопросы:
2. Как понимать, что при старте оно глючит, а потом оказывается исправным?
3. Как дальше диагностировать проблему с сетевым интерфейсом, если в логах нет информации?
4. С какой стати оно что-то делает с iSCSI даже не своих VM?
5. Правильно ли я выбрал режим аггрегирования сетевых интерфейсов? Нагрузка на них тоже далека от перегруза.
PS. Для полноты добавляю: на обоих хостах периодически валятся сообщения вида
2017-03-18T23:59:40.087Z [439C2B70 verbose 'Statssvc.vim.PerformanceManager'] HostCtl Exception in stats collection: Sysinfo error on operation returned status : Not found. Please see the VMkernel log for detailed error information
Нашел в инете некоторые слова по устранению этой проблемы, надеюсь, устранил. Не похоже, чтобы это было причиной зависания, хотя всякое может быть.
Подобные фризы хостов доставали меня регулярно. Исчезли после того, как поменял носитель гипервизора: изначально ESXi устанавливался на USB-флешку, а потом я переустановил его на SSD.
Кстати, один из хостов у меня до сих пор на флешке (всё никак не соберусь вывести его на регламентное обслуживание с заменой на SSD) и как раз он продолжает время от времени "залипать", причём это коррелирует каким-то образом с его iscsi-соединениями с хранилками - по крайней мере рестарт таргетов "разлипает" этот хост.
Спасибо.
Однако у меня сами хосты на винчестерах, причем сами хосты по iSCSI никуда не подключены, это некоторые виртуалки используют iSCSI.
Основное хранилище (где сами виртуалки) подключено по SAS, остальные - по NFS.
Я так понимаю, надо посмотреть состояние проводов, может, какой и отошел. А если проблемы будут продолжаться - проверить винт, на котором установлена система. Тем более, что там не предусмотрено дублирование.
Итак, что же вышло в результате?
1. Я нашел в сети рецепт отключить на всех VM ISO-образы, "вставленные" в CD приводы. Я так и сделал.
2. От этого, или еще от чего, больше висов хоста не было. Это, конечно, ни о чем не говорит, потому что между первым и вторым зависаниями прошло очень много времени.
3. Никаких причин, почему 2 и 3 зависание произошли ровно через неделю, почти в одно и то же время в ночь с субботы на воскресенье, я не нашел.
4. В логах IPMI хоста обнаружились записи о тяжелом аппаратном сбое "OEM CPLD CATERR - Asserted". Время совпадает с временем последних двух зависаний. Причину из этого установить не удалось - это всего лишь сообщение о том, что имела место критическая ошибка процессора (или матери, или обоих). По распространенному в инете рецепту сделали в биосе: Chipset Configuration > North Bridge > Integrated IO Configuration > DCA Support - Disable . Не могу сказать, что это помогло или не помогло, потому как последнее зависание было уже несколько недель назад, а это исправление сделали совсем недавно.
Но ведь второй хост (точно такой же) работает и без этого.
Каждое утро с опаской проверяю состояние хоста и надеюсь на лучшее.