ProHoster > Блог > Администрирование > Корректное завершение работы гипервизора VMWare ESXi при критическом уровне заряда батарей ИБП APC

Корректное завершение работы гипервизора VMWare ESXi при критическом уровне заряда батарей ИБП APC

На просторах есть много статей о том, как настраивать PowerChute Business Edition, и как подключаться к VMWare из PowerShell, но как-то не встретилось все это в одном месте, с описанием тонких моментов. А они есть.

1. Вступление

Несмотря на то, что мы имеем некоторое отношение к энергетике, проблемы с электричеством иногда возникают. Тут в дело вступает ИБП, но и его батареи, увы, не долговечны. Что делать? Выключать!

Пока все серверы были физическими, дела шли неплохо, нас выручала PowerChute Business Edition. Бесплатная, на 5 серверов, чего вполне хватало. На одной машине был установлен агент, сервер и консоль. При приближении конца агент просто выполнял командный файл, в котором на соседние серверы посылалось shutdown.exe /s /m, а потом гасил свою ОС. Все живы.
Потом настало время виртуальных машин.

2. Исходные данные и размышления

Итак, что мы имеем? Всего ничего – один физический сервер с Windows Server 2008 R2 и один гипервизор с несколькими виртуальными машинами, среди которых есть и Windows Server 2019, и Windows Server 2003, и CentOS. И еще ИБП – APC Smart-UPS.

Про NUT мы слышали, но руки пока до его изучения не дошли, использовали только то, что было под рукой, а именно PowerChute Business Edition.

Гипервизор умеет сам завершать работу своих виртуальных машин, осталось только ему сообщить, что пора. Есть такая полезная штука VMWare.PowerCLI, это расширение для Windows Powershell, как раз позволяющее подключаться к гипервизору и сообщить ему все что надо. Про настройки PowerCLI тоже есть много статей на просторах.

3. Процесс

ИБП физически подключили к com-порту сервера 2008, благо он был. Хотя это не принципиально – можно было подключиться через преобразователь интерфейсов (MOXA) к любому виртуальному Windows серверу. Далее все действия производятся на машине, к которой подключена ИБП – Windows Server 2008, если явно не указано иное. На ней установили агента PowerChute Business Edition. Вот тут находится первый тонкий момент: службу агента нужно запускать не от системы, а от пользователя, иначе агент не сможет выполнить cmd-файл.

Далее установили .Net Framework 4.7. Тут требуется перезагрузка, даже если фреймворк ее явно не просит после установки, иначе дальше не пойдет. После еще могут прийти обновления, тоже надо установить.

Далее установили PowerShell 5.1. Тоже требуется перезагрузка, даже если не просит.
Далее установка PowerCLI 11.5. Довольно свежая версия, от этого и предыдущие требования. Можно через интернет, об этом есть много статей, но у нас оно уже было скачано, так что просто скопировали все файлы в папку Modules.

Проверили: 

Get-Module -ListAvailable

Ок, видим, установили: 

Import-Module VMWare.PowerCLI

Да, консоль Powershell конечно запущена от Администратора.

Настройки Powershell.

  • Разрешить исполнение любых скриптов:

Set-ExecutionPolicy Unrestricted

  • Либо разрешить только игнорировать сертификаты скриптов:

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned

  • Разрешить PowerCLI подключение к серверам с недействительными (просроченными) сертификатами:

Set-PowerCLIConfiguration -InvalidCertificateAction ignore -confirm:$false

  • Подавить вывод сообщения PowerCLI о присоедиении к программе обмена опытом, иначе в логе будет много лишнего:

Set-PowerCLIConfiguration -Scope User -ParticipateInCEIP $false

  • Сохранить учетные данные пользователя для входа на хост VMWare, чтоб явно не светить их в скрипте:

New-VICredentialStoreItem -Host address -User user -Password 'password'

Проверка покажет, кого мы сохранили:

Get-VICredentialStoreItem

Можно и подключение проверить: Connect-VIServer address.

Сам скрипт, ну например: подключились, погасили, на всякий случай отключились, возможны варианты:


    Connect-VIserver -Server $vmhost 
    Stop-VMHost $vmhost -force -Confirm:$false 
    Disconnect-VIserver $vmhost -Confirm:$false

4. Default.cmd

Тот самый командный файл, который запускается агентом APC. Лежит в “C:Program Files[ (x86)]APCPowerChute Business Editionagentcmdfiles”, а внутри:

«C:Windowssystem32WindowsPowerShellv1.0powershell.exe» -File «C:…shutdown_hosts.ps1»
Вроде все настроили и проверили, даже запустили cmd – отрабатывает правильно, выключает.

Запускаем из консоли APC проверку командного файла (там есть кнопка Test) – не работает.

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

5. Катарсис

Смотрим диспетчер задач, видим – промелькнуло cmd, промелькнуло powershell. Приглядываемся повнимательней – cmd *32 и, соответственно, powershell *32. Понимаем, что служба агента APC 32-разрядная, а значит она запускает соответствующую консоль.

Запускаем powershell x86 от администратора, проделываем еще раз установку и настройку PowerCLI из пункта 3.

Ну и меняем строчку вызова powershell:

"C:Windows<b>SysWOW64</b>WindowsPowerShellv1.0powershell.exe…

6. Happy end!

Источник: habr.com