PCNS trying to logon unsuccessfully to ESXi hosts every minute

[BillP]

Hi All. 

We use PowerChute Network Shutdown as appliance for ESXi 6.0

There are many error in Event Console at VSphere every minute for both hosts RU-VMH1 and RU-VMH3 (see screenshot).

10.5.3.43 - address of PCNS. Errors means that PCNS is trying (unsuccesfull) to login as root to hosts.

In PCNS config we configured credentials to connect to vCenter, not hosts directly.

Why PCNS tryes to connect to hosts ? Why it happens ? How to fix ?

Thanks.

[BillP · Accepted solution]

Alax,

Where is PCNS and vCenter Server running? Are they installed on 1 of the hosts or on stand-alone Windows system? Also, what version of PCNS is installed? If vCenter Server is running as a VM on 1 of the hosts then PCNS needs to communicate with the hosts to be able to power them down once vCenter is powered down. 

this is the shutdown sequence.

1. Network Card reports that the UPS is on battery.

2. Shutdown delay for the On Battery event elapses. PowerChute starts a maintenance mode task on each Host. At the same time it sends a command to turn off the UPS or Outlet Group.

3. PowerChute starts VM shutdown followed by vApp shutdown.

4. VM/vApp shutdown durations elapse and PowerChute gracefully shuts down the vCenter Server VM.

5. vCenter VM shutdown duration elapses.

6. PowerChute starts executing the shutdown command file.

7. Shutdown command file duration elapses. PowerChute shuts down the VMware hosts using the order on the VMware Host Protection page.

8. OS shutdown sequence starts on the PowerChute physical machine.

9. After a 70 second delay the OS starts to shut down.

10. UPS waits for greater of Low Battery Duration/Maximum Required Delay (NonOutlet Aware UPS‟s) or the Outlet Group Power Off Delay (initiated during step 2).

11. UPS turns off after the user-configurable Shutdown Delay time has elapsed or the Outlet Group turns off after the power off Delay elapses.

[BillP]

Hi Bill.

Thanks for quick Responce.

Here is  additional information:

Where is PCNS and vCenter Server running? Are they installed on 1 of the hosts or on stand-alone Windows system?

- They are running separately  as VmWare appliances (Virtual Machines) in Cluster. 

Also, what version of PCNS is installed?

- PCNS version is up to date (PowerChute Network Shutdown 4.1.0 Build 6428).

If vCenter Server is running as a VM on 1 of the hosts then PCNS needs to communicate with the hosts to be able to power them down once vCenter is powered down. 

- Where in PCNS we can set credentials for 2 hosts (credentials for vCenter is not the same for hosts root access).

BR,

Alex

[BillP · Accepted solution]

Alex,

You should create a local account on the vCenter Server appliance that PCNS will use to communicate with vCenter and the host. Then create the same account on each of the hosts. Application Note 180 discusses adding local accounts and we have Knowledge Base document FA241010 that discusses how to add the local account to vCenter when running on a Windows VM and how to add the local accounts to each hosts. I recommend you review Application Note 180 and use Kbase FA241010 as a guide to help with adding the local account to the hosts if vCenter is running on the Linux appliance. 

[BillP]

Hi Bill,  many thaks! 

Configured vCenter and Hosts with one user psnsadmin - warnings are gone away from logs. 

BR,

Alex Matveev

[fluxtor]

Hi, resurrecting this old post as I'm having the same issue. I followed the guide in Application Note 180 (or at least I think I have) and I'm still experiencing the error in the event log on vCenter Server. Our vCenter is running as an appliance on linux and as a vm on the host. I added a user to vCenter using the terminal/shell which was already a user on the host. The users have the same credentials and are in the administrators groups on both the vCenter and Host.

I've checked that PCNS Client can communication with these credentials and it can but as above I'm still receiving the errors in the event log on the server.

We are running PCNS 4.4.2.

TIA

EDIT: I think I may have fixed by simply changing from localos\user to user@localos 🙂