Graceful shutdown of VMWare ESXi hypervisor at critical battery level of APC UPS

There are many articles in the open spaces about how to set up PowerChute Business Edition, and how to connect to VMWare from PowerShell, but somehow all this did not meet in one place, with a description of subtle points. And they are.

1. Introduction

Despite the fact that we have something to do with energy, problems with electricity sometimes arise. This is where the UPS comes into play, but its batteries, alas, are not durable. What to do? Turn off!

While all the servers were physical, things were going well, we were rescued by PowerChute Business Edition. Free, for 5 servers, which was enough. Agent, server and console were installed on one machine. When the end approached, the agent simply executed a batch file in which shutdown.exe /s /m was sent to neighboring servers, and then extinguished its OS. Everybody is alive.
Then it was time for virtual machines.

2. Background and reflections

So what do we have? Nothing at all - one physical server with Windows Server 2008 R2 and one hypervisor with several virtual machines, among which are Windows Server 2019, and Windows Server 2003, and CentOS. And another UPS - APC Smart-UPS.

We heard about NUT, but we haven’t gotten around to studying it yet, we used only what was at hand, namely PowerChute Business Edition.

The hypervisor is able to shut down its virtual machines itself, it remains only to tell it that it's time. There is such a useful thing VMWare.PowerCLI, this is an extension for Windows Powershell, which just allows you to connect to the hypervisor and tell it everything you need. There are also many articles about PowerCLI settings in the open spaces.

3. Process

The UPS was physically connected to the com port of the 2008 server, since it was. Although this is not important - it was possible to connect through an interface converter (MOXA) to any virtual Windows server. Further, all actions are performed on the machine to which the UPS is connected - Windows Server 2008, unless otherwise specified. The PowerChute Business Edition agent was installed on it. Here is the first subtle point: the agent service must be run not from the system, but from the user, otherwise the agent will not be able to execute the cmd file.

Next, we installed .Net Framework 4.7. This needs a reboot, even if the framework does not explicitly ask for it after installation, otherwise it will not go further. After that, updates may still come, you also need to install.

Next, we installed PowerShell 5.1. It also needs a reboot.even if he doesn't ask.
Next install PowerCLI 11.5. Pretty fresh version, from this and previous requirements. It is possible via the Internet, there are many articles about this, but we already downloaded it, so we simply copied all the files to the Modules folder.

Checked:

Get-Module -ListAvailable

Ok, we see, installed:

Import-Module VMWare.PowerCLI

Yes, the Powershell console is of course run as Administrator.

Powershell settings.

  • Allow execution of any scripts:

Set-ExecutionPolicy Unrestricted

  • Or allow only to ignore script certificates:

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned 

  • Allow PowerCLI to connect to servers with invalid (expired) certificates:

Set-PowerCLIConfiguration -InvalidCertificateAction ignore -confirm:$false

  • Suppress the PowerCLI message about joining the experience exchange program, otherwise there will be a lot of extraneous in the log:

Set-PowerCLIConfiguration -Scope User -ParticipateInCEIP $false

  • Save the user's login credentials to the VMWare host so that they are not explicitly shown in the script:

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

Checking will show who we have saved:

Get-VICredentialStoreItem

You can also check the connection: Connect-VIServer address.

The script itself, well, for example: connected, turned off, just in case, disconnected, options are possible:


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

4.Default.cmd

The same batch file that is launched by the APC agent. Lies in “C:Program Files[ (x86)]APCPowerChute Business Editionagentcmdfiles”, and inside:

"C:Windowssystem32WindowsPowerShellv1.0powershell.exe" -File "C:…shutdown_hosts.ps1"
It seems that everything was set up and checked, they even launched cmd - it works correctly, turns it off.

We start the test of the batch file from the APC console (there is a Test button) - it does not work.

Here it is, that awkward moment when all the work done came to nothing.

5. Catharsis

We look at the task manager, we see - cmd flashed, powershell flashed. Let's take a closer look - cmd * 32 and, accordingly, powershell * 32. We understand that The APC Agent service is 32-bit, which means it launches the appropriate console.

We start powershell x86 as an administrator, we do the installation and configuration of PowerCLI again from step 3.

Well, we change the powershell call line:

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

6. Happy ending!

Source: habr.com

Add a comment