Очень жесткий shutdown зависшей VM

ESXi 6.5 patch 02

Случилось так, что пара VM с установленной Windows 7 зависли от слова совсем. На машинках установлены VMware Tools. Корректно сделать Restart Guest VM не получалось - зависало. Reset VM так же зависало. Вооружаемся PowerCLI, подключаемся к vCenter или ESXi хосту и выполняем:

Get-VM vmname | Stop-VM

Так же зависает. И тут нам на помощь приходит волшебный ключик kill 

Get-VM vmname | Stop-VM -kill

После этого VM выключается, стартуем ее, радуемся. 

VNX 1го поколения (5500), обновление до 05.32.000.5.225

Техническая поддержка до нового года прислала радостное сообщение, что вышло обновление Block OE для VNX 1го поколения 05.32.000.5.225 и нужно бы запланировать это самое обновление. У нас была установлена 05.32.000.5.221.

В самом по себе обновлении нет ничего сложного, была выслана инструкция, единственное, что надо не забыть отжать галочку disruptive update, что бы обе SP не ушли в ребут одновременно.

Ну и даже в случае с ребутом по очереди, проверьте настройки зон, multipathing'a, что бы хост внезапно не потерял свои LUN'ы.

Обновились, все хорошо. После обновления обычно генерируются логи с обоих SP и отправляются в ТП на исследование - все ли прошло хорошо. 

Обновление прошло, даю команду Generate Diagnostic files SPA, Generate Diagnostic files SPB, немного жду. Жму Get Diagnostic files SPA, скачиваю логи, жму Generate Diagnostic files SPB и получаю ошибку:

Так-так, подумал я... Отписал в саппорт. 

Долго думали как быть и что делать, в итоге поехал в ЦОД со шнурком, что бы подключиться в Service LAN и дать ТП доступ до Remotely Anywhere.

И вот тут я могу кого-то удивить... Внутри VNX 1го поколения установлена Windows 2008 R2  (так же на корпусе присутствует лицензионная наклейка) :)

Мучали-мучали, через Remotely Anywhere логи выгружаются, а через Unisphere нет. 

Итогом оказалось письмо от ТП, что 225 прошивка кривая, логи слить нельзя, некоторые визарды не работают, поправят в следующей прошивке, но когда она выйдет - не знают, но на работоспособность не влияет. Да, это отлично, только в случае проблем мне каждый раз ехать на другой конец города и втыкаться в Service LAN, что бы слить логи?

Был предложен второй вариант, не очень веселый: reimage массива, т.е. откат прошивки и к заводским настройкам. Благо, массив этот использовался для VMware, еще перед обновлением все виртуалки уехали через Storage vMotion на другие массивы. Будем сбрасывать.

Не обновляйтесь до 05.32.000.5.225!!!

Невозможно сделать Export System Logs с хоста esxi через web client

esxi 6.5.0d

Нажимаем на хосте Export System Logs, а в окошке выбора логов пусто.
Кто-то где-то когда-то подправил в конфигах порты...

1. Идем на хост по ssh
2. vi /etc/vmware/rhttpproxy/endpoints.conf
3. Ищем запись /cgi-bin
4. Меняем значение порта на 8303
5. Сохраняем и выходим
6. /etc/init.d/rhttpproxy restart
7. /etc/init.d/hostd restart

Радуемся.

После обновления до 6.5.0 patch 02 проблема самоустраняется.

Esxtop DAVG/cmd и KAVG/cmd ОГРОМНЫЕ показатели

Столкнулся с проблемой: esxtop в режиме отображения загрузки LUN'ов показывает девятизначные показания, что, естественно, не может быть правдой. Проблема выяснилась случайным образом, когда виртуальные машины, использующие datastore с этого массива начали дико тормозить, показатель io wait начал расти, некоторые виртуалки даже успели потерять диски. 

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

Картина выглядела вот так:

С массивом действительно была проблема, но эти показатели не соответствуют действительности. Оказывается, проблема известная, есть у VMware KB по этому поводу:

https://kb.vmware.com/s/article/2096171

В статье говорится, что в VMware ESXi 6.0 Update 1b и  VMware ESXi 6.5.x проблема устранена. У меня установлен ESXi 6.5.0d, проблема имеет место быть.

На днях буду проводить обновление до ESXi 6.5 Patch 02, по результатам обновлю топик.
upd от саппорта VMware:
"Я уточнил на наших внутренних ресурсах, по данной проблеме сейчас ведется работа (воздействие на 6.5)
Прошу Вас подписаться на KB https://kb.vmware.com/kb/2096171 ( Subscribe to Article ) чтобы получить уведомление когда выйдет fix."