August 2019 – vMind.ru

VMware vSphere 6.7 Update 3 Alarm ‘Host hardware sensor state’

У VMware есть привычка в практически каждый релиз заложить какую-нибудь граблю. Вот и в vSphere 6.7 Update 3 отличились.

Выражается в виде массовых событий типа error в vCenter Events:

 Alarm 'Host hardware sensor state' on [hostname] triggered by event [number] 'Sensor -1 type , Description [device] state assert for . Part Name/Number N/A N/A Manufacturer N/A'.

1	Alarm 'Host hardware sensor state' on [hostname] triggered by event [number] 'Sensor -1 type , Description [device] state assert for . Part Name/Number N/A N/A Manufacturer N/A'.

Функционал вроде бы не нарушен, проявляется на оборудовании разных производителей, но эти же события имеют тип info в ESXi.

Проблема в том, что данные события переполняют логи vCenter и систем мониторинга.

Участник Reddit пишет:

Our vCenter daily log is usally something like 15-20KB, but it has blown up to 1.7-2.3 GB since the 10-node upgrade.

То есть рост логов в сутки составил всего-то сто тысяч(!) раз.

А что поддержка? Ничего – ещё не признали проблему! Видать, все на VMWorld уехали.

Update

VMware признала проблему и предложила пару обходных решений в базе знаний – Excessive Hardware health alarms being triggered for “Sensor -1 type” on ESXi hosts running vSphere 6.7 U3 (74607).

Останов VCSA при нехватке места

У нас неожиданно стал прекращать работать VCSA, а конкретно сервис VPXD.

Стартнёшь ручонками – работает то десяток часов, то 20 минут. Из warning’ов – мало места для базы данных (List of VMDKs/Partitions for a vCenter Server Appliance 6.7 – Size Mount point and Purpose (70625)). VAMI показывает, что места в SEAT занято 90%. Также не работает Update Manager даже при запущенном VPXD. Все логи vpxd.log перебрали – ничего не заметили, как будто штатный останов.

Написали в техподдержку – те попросили логи собрать, а как их соберёшь, если vCenter то потухнет, то погаснет. Кое-как собрали через VAMI, да и те оказались не полные, пришлось ручонками скопировать с помощью WinSCP папку логов VPXD.

Поддержка логи смотрела внимательнее и нашла:

2019-08-27T06:50:34.343Z error vpxd[102197] [Originator@6876 sub=vpxdVdb] Shutting down the VC as there is not enough free space for the Database(used: 95%; threshold: 95%).
2019-08-27T06:50:34.343Z info vpxd[102197] [Originator@6876 sub=Default] Initiating VMware VirtualCenter shutdown
2019-08-27T06:50:35.412Z error vpxd[102111] [Originator@6876 sub=vpxdVdb] Insufficient free space for the Database (used: 95%; threshold: 95%)

2019-08-27T06:50:34.343Z error vpxd[102197] [Originator@6876 sub=vpxdVdb] Shutting down the VC as there is not enough free space for the Database(used: 95%; threshold: 95%).

2019-08-27T06:50:34.343Z info vpxd[102197] [Originator@6876 sub=Default] Initiating VMware VirtualCenter shutdown

2019-08-27T06:50:35.412Z error vpxd[102111] [Originator@6876 sub=vpxdVdb] Insufficient free space for the Database (used: 95%; threshold: 95%)

Действительно, места не хватает и VPXD сам себя отправляет отдыхать. Описание поведения vCenter есть КБ-шечке “Shutting down the VC as there is not enough free space for the Database” error (67017). Вот только она про /storage/db, а про /storage/seat умалчивает.

Добавили место у диска SEAT по инструкции Increasing the disk space for the VMware vCenter Server Appliance in vSphere 6.5 and 6.7 (2145603). Перезагрузили VCSA и всё заработало.

P.S. Так и не понял – с каких пор 90%=>95%?

P.P.S. Андрей подсказал откуда разница в процентах (данные после увеличения диска):

Вывод в VAMI: seat Total space 54.0 GB Used space 32.4 GB Available space 21.6 GB 60.1% of 54.0 GB

Вывод в df -h: /dev/mapper/seat_vg-seat 55G 33G 19G 64% /storage/seat

Изменение ссылки на сервер мониторинга в Skype for Business

После того, как вы развернете Monitoring Database на SQL Reporting Services, в SkypeFB/Lync Control Panel появится ссылка на веб-интерфейс с отчетами:

Однако при переносе отчетов на другой сервер ссылка автоматически не обновляется.

Для исправления проделаем следующее:

Запомним строку, выделенную красным цветом:
Service:1-MonitoringStore-13
Удалим эту конфигурацию из PowerSHell CLI:

Remove-CsReportingConfiguration -Identity Service:1-MonitoringStore-13

1

Remove-CsReportingConfiguration -Identity Service:1-MonitoringStore-13
Найдем актуальный сервер отчетов:

Get-CsService | where {$_.Identity -like "*monitoring*"} | fl identity Identity : MonitoringDatabase:skypefb-mon.holding.com

1
2
3

Get-CsService | where {$_.Identity -like "*monitoring*"} | fl identity

Identity : MonitoringDatabase:skypefb-mon.holding.com

Создадим новую конфигурацию отчетов:

New-CsReportingConfiguration -Identity “Service:MonitoringDatabase:skypefb-mon.holding.com” -ReportingUrl "https://skypefb-mon.holding.com/reports/report/LyncServerReports/Reports%20Home%20Page"

1	New-CsReportingConfiguration -Identity “Service:MonitoringDatabase:skypefb-mon.holding.com” -ReportingUrl "https://skypefb-mon.holding.com/reports/report/LyncServerReports/Reports%20Home%20Page"

Поиск переадресации в Exchange

Коллеги поделились рецептом:

Пользователь получает чужую рассылку, направленную 100500 получателям.

Возник вопрос – как узнать на ком из этих получателей стоит переадресация на этого пользователя.

А вот ответ с фильтрацией по имени сервера, которое можно обнаружить в трекинге почтовых сообщений:

Get-mailbox -server mbx02| select DisplayName,ForwardingAddress | where {$_.ForwardingAddress -ne $Null}|out-gridview

1	Get-mailbox -server mbx02\| select DisplayName,ForwardingAddress \| where {$_.ForwardingAddress -ne $Null}\|out-gridview

Доступность инструкций процессора в зависимости от версии vHW

Ранее на бложике публиковались две статьи о разном поведении виртуальных машин при разном vHW и EVC

Один из участников сообщества VMUG провел анализ доступных инструкций процессора в зависимости от версии виртуального железа с помощью утилиты /proc/cpuinfo. В результат появилась занимательная таблица:
Исходник в Google Таблицы.

P.S. Комментарий автора:

После обсуждения CPUID решил проверить зависимость доступных инструкций от vHW, но основной вывод уже был сделан в КВ по процессорным уязвимостям: “безопасной” версией является 9, а тормозить оно перестаёт на 11. Также выяснилось:
1. vHW режет флаги не так сильно, как EVC. Например, на vHW=8 доступны fma и movbe (Haswell), а на vHW=13 доступны xsavec и xsaves (Skylake).
2. Между 13-16 версиями без NVDIMM и гостевой виртуализации нет разницы.