When I first looked at automated vSphere shutdowns via UPS signaling for an APC UPS the path of least resistance seemed to be using one of the PowerChute applications on an instance of the vSphere Management Assistant (vMA). With deprecation warnings aplenty for the vMA, that wasn’t a path I was interested in pursuing. However, more recently I discovered PowerChute Network Shutdown for Virtualization has a virtual appliance available.
I found the “Installation Guide: PowerChute Network Shutdown v4.2” to be the most straightforward description of what was required.
Following the “Preliminary Steps in Installing” section on the Network Management Card one must:
- Configure network management card with an IP address.
- Configure a Low Battery Duration and Authentication Phrase on the network management card. (Both under Configuration -> Shutdown)
- Additionally I enabled HTTPS access to the management card via Configuration -> Web Settings.
Following this, once deploys the OVA appliance. – If your environment includes vSAN hosts, there are some additional considerations noted that did not apply to the deployment I’m describing.
I was able to use the flash-based webclient to deploy the appliance to a vSphere 6.0 environment, following these steps:
- Deploy OVA, specifying VM deployment options (host, datastore, network) and TCP/IP configuration (IP address, subnet mask, gateway, DNS servers). While the deployment guides notes the TCP/IP configuration values are not applicable for a single host deployment, I didn’t see these applied when deployed to a vSphere environment.
- Configure appliance root password, accept EULA, set timezone, and finally configure networking. These steps were completed in this order via virtual machine console. I found that setting the root password as the first todo item is very important, otherwise, some of the options will log you out without an obvious way back into the configuration interface.
- Install updates via yum update, per referenced install guide
- Load setup wizard in a web browser (https on port 6547)
Following this configuration is completed via the web interface and a wizard driven setup. If you’re following the documentation, you’ll need to switch to “User Guide PowerChute Network Shutdown v4.2 VMware.” However, the wizard prompts are fairly self-explanatory. From the web-based setup wizard, the following steps were completed:
- Selected IPv4 networking.
- Selected Host managed by vCenter Server.
- Configured connection to vCenter Server, currently using root account. Included in this was noting that the vCenter Server is a VM.
- Selected Single UPS configuration.
- Supplied account details and authentication phrase for network management card.
- Supplied network management card address and protocol (HTTPS).
- Selected Hosts powered the UPS previously selected. Also at this point verified te host hosting both the PowerChute VM and the vCenter VM were correctly identified.
- Selected the Outet Group the system was plugged into. (Selected UPS Outlets)
- Virtualization Settings:
- as the hosts in this configuration do not have similar hardware and all need to get shutdown, did not enable VM migration.
- selected VM shutdown, increased the time allowed for VMs to shutdown, did not select VM startup when power returns.
- as no vApps are deployed, did not configuration the option to shutdown vApps.
- left vCenter Server VM shutdown duration at default 240 seconds.
- did not register the vCenter Plug-in at this time.
This completed setup of the components, there was only testing left to be done.
For testing this configuration I logged back in the UPS and adjusted the “Low Battery Duration” to the maximum value (30 minutes) in an effort to quickly trigger the shutdown. I compared the remaining runtime (Status -> UPS Status) and new Low Batter Duration to gauge how long the test would take, made sure I access to the vCenter events while in front the UPS and pulled the plug.
I was easily able to verify that all the VMs that weren’t the vCenter server or the PowerChute appliance where issued appropriate shutdown commands as was the host that wasn’t hosting the two running VMs. Verifying that the remaining two VMs were shutdown correctly has proven a bit more challenging. At this point, while everything came back up, I’m becoming convinced that there’s some more work to do to get those last couple of virtual machines (including vCenter) shutdown cleanly. While further adventures await, this is a much improved situation over having nothing in place.
