Видеозаписи докладов с VMworld 2019 доступны на страницах:
Category: VMware
VMware vSphere 6.7 Update 3 Alarm ‘Host hardware sensor state’
У VMware есть привычка в практически каждый релиз заложить какую-нибудь граблю. Вот и в vSphere 6.7 Update 3 отличились.
Выражается в виде массовых событий типа error в vCenter Events:
|
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.
Поддержка логи смотрела внимательнее и нашла:
|
1 2 3 |
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
Доступность инструкций процессора в зависимости от версии 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 и гостевой виртуализации нет разницы.
Релиз платформы VMware vSphere 6.7 Update 3
Компания VMware выпустила обновление своей платформы виртуализации VMware vSphere 6.7 Update 3:
VMware ESXi 6.7 Update 3 Release Notes
VMware vCenter Server 6.7 Update 3 Release Notes
VMware vSAN 6.7 Update 3 Release Notes
Проблемы с VMware HA после обновления vCenter
Майское обновление vCenter 6.0 (U3i) и 6.5 (U2d) вывело из строя несколько кластеров vSphere HA. Симптомы были одинаковые: часть узлов кластера не может связаться с мастером. Лечение, увы, отличалось:
- части узлов хватило переконфигурировать HA-агента;
- часть узлов пришлось выводить в режим обслуживания и перезагружать.
Увидеть ситуацию помогли Alarms, сработавшие на хостах.
P.S. Не все обновления одинаково полезны…
Настройка разрешений на vCenter
Как-то потребовалось мне решить задачу “сосуществования” в рамках vCenter нескольких команд администраторов, обслуживающих свои кластера vSphere.
В vSphere есть достаточно гибкий механизм предоставления полномочий вплоть до отдельной виртуальной машины, однако выяснилось, что есть ряд полномочий, задающихся не на уровне кластера хостов или папки виртуальных машин.
Данные о ВМ в vMotion Wizard
Про полезняшки в новых версиях vSphere мы уже писали ранее: о флешовом клиенте в статье Фильтры, задания и снимки в VMware vSphere 6.7, о ESXi-ом клиенте в Просмотр логов на ESXi.
Сегодня заметка о новой фишке vMotion Wizard – VM origin.
Часто бывает, что запустил перемещение виртуальной машины со сменой хоста и хранилища и тут приходит мысль “а сейчас-то как машина размещена?”.
Разработчики HTML5-клиента решили это дело упростить и сделали подсказку – достаточно щёлкнуть VM origin:
Развертывание виртуальной машины vSphere через PowerSHell часть 1
Стал задаваться вопросом – как автоматизировать выполнение рутинных операций в vSphere?
Лучше бы не задавался 🙂
Начал с задачи “развернуть виртуальную машину из шаблона с указанной кастомизацией гостевой операционной системы”.
Основные проблемы, с которыми я столкнулся:
- мною использовалась настройка кастомизации ОС “Prompt User”, спрашивающая только IP-адрес (подразумевается, что развертывание происходит в одно и то же адресное пространство). Как оказалось, проще использовать передачу “всех” параметров IP в скрипте;
- перемещение учетной записи сервера после ее развертывания для применения групповых политик в другой контейнер Active Directory;
- поле “Notes” получает строку. Как передать ей несколько строк, если потребуется перевод строки, я пока не разбирался;
- за кадром остались процессы дальнейшей настройки сервера – установка обновлений и дополнительного ПО. Это будет рассмотрено в следующих частях статьи.
Вдохновлялся я скриптом, опубликованным здесь.
А вот что получил:
|
1 2 3 4 5 6 7 8 9 10 11 |
Get-OSCustomizationSpec -Name windows | New-OSCustomizationSpec -Name temp1 -Type NonPersistent Get-OSCustomizationSpec -Name temp1 | Get-OSCustomizationNicMapping | Set-OSCustomizationNicMapping -IpMode UseStaticIP -IpAddress '10.0.0.1' -SubnetMask '255.255.255.0' -DefaultGateway '10.0.0.254' -Dns '10.0.0.254','10.0.0.253' New-VM -Name 'new-vm' -Template (Get-Template windows_template) -OSCustomizationSpec (Get-OSCustomizationSpec 'temp1') -ResourcePool (Get-ResourcePool -Name 'Resources'-Location 'Cluster_Name') -Datastore (Get-DatastoreCluster -Name 'Datastore_Cluster') -Notes "Zdes mogla by byt vasha reklama" Start-VM -VM new-vm Do {Get-ADComputer -identity new-vm -ErrorAction SilentlyContinue;write-host "." -nonewline -f red;sleep 3} until(Get-ADComputer -identity new-vm -ErrorAction SilentlyContinue -warningaction silentlycontinue) Move-ADObject -identity (Get-ADComputer -identity new-vm).distinguishedname -TargetPath "OU=Servers,DC=DOMAIN,DC=COM" Do {$tools=(Get-VM -Name new-vm).ExtensionData.Guest.ToolsStatus;write-host "." -nonewline -f red;sleep 3} until(($tools -eq "toolsOk") -or($tools -eq "toolsOld")) Restart-VMGuest -VM new-vm -Confirm:$false Start-Sleep -Seconds 10 Do {$tools=(Get-VM -Name new-vm).ExtensionData.Guest.ToolsStatus;write-host "." -nonewline -f red;sleep 3} until(($tools -eq "toolsOk") -or($tools -eq "toolsOld")) Write-Host("Server is ready!") |
Данный скрипт берет гостевую кастомизацию “windows” (Guest Customization OS) и создает на ее основе временную кастомизацию “temp1”.
Затем скрипт задает настройки IP, которые должна будет получить новая ВМ.
Далее мы создаем виртуальную машину из шаблона “windows_template”, используя подготовленную кастомизацию “temp1”. Машина создается в кластере “Cluster_name” с примечанием о том, для чего нужна эта ВМ. Диски шаблона при этом клонируются на кластер хранилищ (Datastore Cluster) с названием “Datastore_Cluster”.
Затем мы включаем виртуальную машину и ждем.
Ждем мы до тех пор, пока в AD не появится учетная запись компьютера. А эта запись должна появиться там потому, что в гостевой кастомизации настроено автодобавление ПК в домен.
Как только мы этого дождались, мы перекладываем эту учетную запись ПК в соответствующую OU.
Проверяем статус VMware Tools и, если они работают, перезагружаем наш сервер для применения актуальных групповых политик.
Затем ждем 10 секунд пока VMware Tools 100% остановятся в ходе перезагрузки, ждем пока они будут запущены и выводим на экран сообщение о том, что сервер готов.
VMware PSC replication
Компонент Single Sign On, выполняющий проверку подлинности, появился в VMware vSphere 5.1. К vSphere 5.5 он стал “адекватнее” и стабильнее.
Его можно было поставить как на отдельный сервер, так и совместить вместе с vCenter Server.
В vSphere 6 этот компонент был объединен с другими сервисами в роли Platform Service Controller.
С тех пор и до vSphere 6.7 (или 6.7 Update 1) рекомендуемой схемой высокодоступного размещения PSC была следующая:
- Несколько внешних/отдельных PSC-серверов. Размещать PSC совместно с vCenter и реплицировать данные не некомендовалось.
- Требовался балансировщик между PSC и vCenter-серверами (хотя я видел скрипты, переключающие vCenter на резервный psc при недоступности основного).
Наверное, особенно круто было заниматься обновлением этого зоопарка из 4+ систем.
Особенно я прослезился со следующего KB – правила репликации PSC, рассказавшего о том, что репликация происходит в том порядке, в каком ранее добавлялись PSC (если развернули первый, на него нацелили второй, на второй – третий, то и репликация пойдет по такой схеме). Все связи между SSO-службами добавляются и удаляются только вручную.
Попутно узнал, что рекомендуемая топология – c центральным PSC.
Еще несколько KB:
- удаление PSC;
- переключение на другой PSC;
- резервное копирование и восстановление PSC.
А теперь к хорошим новостям: забудьте все, что только что прочитали 🙂
Начиная с vCenter 6.7 рекомендуемой топологией является встроенный PSC для любой топологии. Вы даже можете сделать vCenter HA (vCenter High Availability) для встроенного PSC, если хотите его защитить.
Ну и к вопросу резервной копии – в v6.7 появился ручной File-Based Backup, позволяющий сделать бэкап системы vCenter+PSC, восстанавливаемой с нуля с помощью этих файлов.
А в v6.7 Update 1 – возможность запуска бэкапа по расписанию.
В общем, администрирование нескольких vCenter-серверов в v6.7 стало значительно легче.