Virtual Machine and Virtual Appliance Shutdown/Startup

To ensure graceful Virtual Machine (VM)/Virtual Appliance (vApp) shutdown due to a UPS critical event, each VM/vApp must have VMware Tools installed. The Duration field is the time allowed for all the VMs/vApps to gracefully shut down.

If the VMs/vApps are shut down before the Duration time, PowerChute waits until this time has elapsed before proceeding to the next step in the sequence.

Using the Duration field, you must allow sufficient time for all your VMs/vApps to gracefully shut down before the hosts are commanded to shut down.

For vApps, the Shutdown Action - Operation must be changed from Power Off to Guest Shutdown to ensure that the VMs in the vApp are shut down gracefully. This can be edited through vCenter Server. Right-click the vApp in the left-hand panel of vCenter Server and click on Edit Settings.

By default, there is a 120 second delay between shutting down each VM in a vApp. The next VM in the vApp will not be shut down until this delay has elapsed or the current VM is powered off. This should be factored into the PowerChute VM/vApp Shutdown duration.

The Force vApp Shutdown check box is selected by default to ensure that, when VMs in the vApp are on different hosts, they are still gracefully shut down even if some hosts are not impacted by the UPS critical event.

If this checkbox is disabled, vApp shutdown will be skipped if some hosts are still not impacted. In addition, only the vApp VMs on the impacted hosts will be shut down. Any VMs running on hosts not impacted by the UPS event will remain running. This may cause issues if there are dependencies between the VMs in the vApp.

If vCenter Server is running on a VM and not added to a priority group, it is shut down once all other VMs/vApps have been shut down. If the vCenter Server VM is added to a priority group, it will be shut down with the other VMs in its priority group. There is a separate duration for shutting down the vCenter Server VM, which is configurable. In a Dell VxRail configuration, the vCenter Server VM cannot be added to a priority group as it is required for the NMC to authenticate with VxRail Manager. PowerChute shuts itself down after sending the request to the NMC to shut down the VxRail cluster following this delay.

If PowerChute is running on a VM, it does not get shut down as it is needed to shut down the VMware hosts. The PowerChute VM will be powered off when the VMware host on which it is running is shut down. If HA is enabled, the PowerChute VM will be restarted automatically once there is a healthy host available in the cluster. See HA Admission Control.

Shutting down a primary vApp with nested vApps

During the PowerChute shutdown sequence, vApps are shut down in no particular order in accordance to their priority group. To shut down a primary vApp (a vApp containing vApps) and exclude the nested vApps in the primary vApp, you can use the VM Prioritization screen:

1. In the VM Prioritization screen, add the primary vApp to a priority group (for example, Medium).
2. Add the nested vApps to a lower priority group (for example, Group 1).
3. In the Set VM Shutdown Duration section of the VM Prioritization screen, provide a sufficient duration for the medium priority group to gracefully shut down. For example, set the shutdown duration for the medium priority group to 240 seconds.
4. Set the shutdown duration for the Group 1 priority group to 0 seconds. If you set a 0 second shutdown duration for a priority group, PowerChute will not shut down the VMs/vApps in this priority group.

Re-starting after a shutdown

Selecting Enable VM/vApp Startup re-starts any VMs/vApps that were shut down when a UPS critical event has been resolved and the VMware Hosts are powered on. PowerChute first checks that the VMware host is powered on and connected to vCenter Server.

In Single and Redundant, and Parallel UPS configurations, the option Wait for all Hosts Online is selected by default. When selected, PowerChute waits until all hosts in the cluster are back online before starting the VMs/vApps. The VMs/vApps are started on each host in parallel.

If vCenter Server is running on a VM and it was shut down by PowerChute, and in a Dell VxRail stretched cluster configuration, PowerChute waits until its host comes back online before powering that VM on. PowerChute will then wait for vCenter Server to start before it starts the rest of the VMs/vApps.

Disable option Wait for all Hosts Online to allow PowerChute to attempt to start VMs/vApps on VMware hosts as they become available. If the vCenter Server VM Host is available when other Hosts are online, PowerChute will attempt to start the vCenter Server VM and then start VMs/vApps on other hosts.

If vCenter Server was offline or unavailable when VMs/vApps were shut down, PowerChute will start the VMs/vApps by connecting directly to the VMware hosts when they come back online after the UPS critical event has been resolved.

In Advanced UPS configurations, the option Wait for all Hosts Online is also selected by default. Where vCenter Server is running on a VM that is shut down by PowerChute, PowerChute waits for the vCenter Server host to come back online and then starts the vCenter Server VM, before attempting to start VMs/vApps on other hosts. If the Wait for all Hosts Online option is disabled, PowerChute will attempt to start VMs/vApps on VMware hosts as they become available.

In the PowerChute configuration file (pcnsconfig.ini), the "delay_before_vmstartup" setting allows you to delay VM/vApp start up until the user-specified duration has elapsed. This setting can be used to ensure that cluster/vSAN services have successfully started before attempting to start up the VMs/vApps in the cluster. This setting can be found in the [HostConfigSettings] section of the configuration file and the default value is 0. This setting is only relevant in a Dell VxRail stretched cluster configuration.

Unsuccessful VM/vApp Startup

If VM/vApp startup is unsuccessful, PowerChute will wait the time specified in the VM/vApp Startup Duration field before attempting to restart the VMs/vApps, and the below entries are logged to the Event Log:

• Attempting to power on VMs on Host [Host] that did not start.
• Attempting to power on vApp [vApp] in datacenter [Datacenter] that did not start.

 If VM/vApp startup is unsuccessful on the second attempt, no further startup attempts are made.

HA Admission Control

HA Admission Control is enabled by default in vSphere. To change Admission Control settings, click on a Cluster in the Inventory, select Configure. Click vSphere Availability, and click Edit.

If PowerChute is installed on a Virtual Machine, it may not be restarted automatically when its Host is powered on after a critical event has been resolved. This can occur if HA Admission Control is enabled or if the Admission Control policy being enforced prevents it.

To allow the PowerChute VM to get started automatically by HA, disable HA Admission Control or modify the Admission Control Policy to allow the PowerChute VM to start. For more information on HA Admission control settings please refer to VMware documentation.

When Admission Control is disabled, HA will attempt to automatically start the VM on which PowerChute is running and PowerChute can begin to monitor associated UPS devices and automatically restart the VMs that it shut down.

To troubleshoot VM/vApp Startup issues see VMware Troubleshooting.