Remove all servers from XO and log out.

Host 1 is powered off. On host 2.

xe task-list
uuid ( RO)                : 727ecb6b-6f2e-15eb-601b-110b2478996b
          name-label ( RO): Async.host.power_on
    name-description ( RO):
              status ( RO): pending
            progress ( RO): 0.000

xe task-cancel uuid=727ecb6b-6f2e-15eb-601b-110b2478996b

Task is still there.

From XCP-NG Center. Shutdown all VMs and host2 (All powered off).

Powered up both servers.
Wait 15 minutes to make sure no tasks are pending (xe task-list).

Logging output to file via putty of; tail -f /var/log/audit.log

Added host2 (master) to XO Settings/Servers.

The Async.host.power_on task hasn't come back.

Quoting the doc:

Add a host
Just click on "Add server", enter the IP of a XenServer host (ideally the pool master if in a pool)

So yes, in a pool, only the master is needed to connect to all machines.

This is problem from my perspective...

Host1 is the pool master and I added to Settings/Hosts.
I can see host1 and host2 listed in the Home/Hosts list. OK.
I migrated all VMs to host2. OK
Change pool master to host2. OK
If I logout of XO and back in, there are no hosts or VMs listed in Home because XO doesn't know anything about host2.

If XO could ask and retain the IP and credentials of the new master server when it is selected then I could see it working.

What if the root passwords in host1 and host2 are not identical?

As it is now, I must add host2 to Settings/Servers to regain control of the pool. I'm supposed to delete host1 now as well, according to the doc.

XCP-NG Center is what I am familiar with and that is why I added all servers to XO initially. I was expecting XO to operate the same way.

And I still have an active task I can't eradicate.

Async.host.power_on (on host2) 0%

Only complaint in XOA: the Host stays yellow in Busy (shutdown) Mode but even in this mode, the Start button is available and works.

We configured Wake on LAN (WoL) in the BIOS and tested it with a stupid Windows Tool. WoL seems to be way more stable and proven than any other methods and the only downside I see is that it's limited to a Local Range (as it works with MAC Addresses) but I wonder how many pools don't fit in that schema.

Add a host
Just click on "Add server", enter the IP of a XenServer host (ideally the pool master if in a pool)

So yes, in a pool, only the master is needed to connect to all machines.

http://xo/#/settings/servers is only for the pool masters not pool members?

I don't see where it says to not add pool members other than the master
https://xen-orchestra.com/docs/manage_infrastructure.html#home-view

I am grateful for the help but it didn't solve this issue. The task is back.

Both servers are running in the pool.
Both removed from XO.
Toolstack restarted on both servers via XCP-NG Center at 12:50pm local time.
Server communications re-established automatically in XCP-NG Center at 12:52pm.
Pool master added and 2nd server added to XO at 12:54pm.
No tasks are listed on either server with xe task-list.
No tasks are listed in the XO UI.
Powered off server 2 from the server's console screen (not XCP-NG Center or XO being the point).

I have a task in the master on the CLI and XO again.

uuid ( RO)                : 2f820b63-f03a-1258-1443-2f946569a4fb
          name-label ( RO): Async.host.power_on
    name-description ( RO):
              status ( RO): pending
            progress ( RO): 0.000

The only mention of power_on in audit.log since the power up time...

Jul  8 12:48:15 xcpng01 xapi: [20200708T17:48:15.096Z|audit||3666 |Async.host.power_on R:9802e63aaa34|audit] ('trackid=5835f391b350762fbb9dc4eb46b25614' 'LOCAL_SUPERUSER' 'root' 'ALLOWED' 'OK' 'API' 'host.power_on' (('host' 'xcpng02' '1139bfbc-c487-4311-8206-bbffe96ed6b1' 'OpaqueRef:426e950f-f926-490f-b598-328314aafbdc')))

Jul  8 12:48:15 xcpng01 xapi: [20200708T17:48:15.183Z|audit||4625 INET :::80|task.destroy D:39825944bdf5|audit] ('trackid=5835f391b350762fbb9dc4eb46b25614' 'LOCAL_SUPERUSER' 'root' 'ALLOWED' 'OK' 'API' 'task.destroy' (('self' 'Async.host.power_on' '221a86ff-ae3f-d10e-26bc-9a7b693f44f0' 'OpaqueRef:9802e63a-aa34-4f8e-9876-94f0b3778324')))

OK this is interesting (host1 is master). I powered on host2 and ... the task disappeared from xe task-list and XO Tasks.

I powered off host2 again and the task is back.

[12:38 xcpng01 log]# xe task-list params=all
uuid ( RO)                  : 221a86ff-ae3f-d10e-26bc-9a7b693f44f0
            name-label ( RO): Async.host.power_on
      name-description ( RO):
            subtask_of ( RO): <not in database>
              subtasks ( RO):
           resident-on ( RO): cdb42b94-7ec6-47b4-aaef-d4c52f6bd7b3
                status ( RO): pending
              progress ( RO): 0.000
                  type ( RO): <none/>
                result ( RO):
               created ( RO): 20200708T17:37:00Z
              finished ( RO): 19700101T00:00:00Z
            error_info ( RO):
    allowed_operations ( RO): Cancel
    current_operations ( RO):
          other-config (MRW):

Host #2 has been powered off during these checks. I will power it on so that all pool members are available and try xe task-cancel again. Then proceed with your suggestion. Standby.

Weird. Can you disconnect XO from this pool, restart toolstack on master, and see if the task is popping again? I think it will, I don't see why XO would do that.

I would remove the hosts from XO, restart toolstack, add hosts back to XO? Is this correct?

So now everything is back online but despite that you got the task?

Yes, everything is up and working, just the task appears in XO and also on the master's tasks list as we see.

Can you power on that host to see if it stops?

I had the whole rack powered off yesterday, 2 - XCP-NG 8.1 servers (DL380 Gen9), 1 Freenas (DL380 Gen9) for iSCSI VDIs. It still came back.

Going back as far as I can to audit.log.7.gz only takes me back to June 30 and this has been a problem for more than a month so I don't think I can find the original request.

Can you power on that host to see if it stops?

fgrep host.power_on audit.log.1 | fgrep -v destroy | fgrep -v cancel

Jul  7 23:58:02 xcpng01 xapi: [20200708T04:58:02.118Z|audit||36922 |Async.host.power_on R:0af8abcf2f46|audit] ('trackid=68849bbe6e0a22d9b0b024c21c2b6e36' 'LOCAL_SUPERUSER' 'root' 'ALLOWED' 'ERROR:INTERNAL_ERROR: [ (Failure \"The host failed to power on.\") ]' 'API' 'host.power_on' (('host' 'xcpng02' '1139bfbc-c487-4311-8206-bbffe96ed6b1' 'OpaqueRef:426e950f-f926-490f-b598-328314aafbdc')))

Jul  8 00:58:02 xcpng01 xapi: [20200708T05:58:02.803Z|audit||42462 |Async.host.power_on R:2733002e2e58|audit] ('trackid=68849bbe6e0a22d9b0b024c21c2b6e36' 'LOCAL_SUPERUSER' 'root' 'ALLOWED' 'ERROR:INTERNAL_ERROR: [ (Failure \"The host failed to power on.\") ]' 'API' 'host.power_on' (('host' 'xcpng02' '1139bfbc-c487-4311-8206-bbffe96ed6b1' 'OpaqueRef:426e950f-f926-490f-b598-328314aafbdc')))

Jul  8 01:58:03 xcpng01 xapi: [20200708T06:58:03.488Z|audit||48005 |Async.host.power_on R:e74dd3d29556|audit] ('trackid=68849bbe6e0a22d9b0b024c21c2b6e36' 'LOCAL_SUPERUSER' 'root' 'ALLOWED' 'ERROR:INTERNAL_ERROR: [ (Failure \"The host failed to power on.\") ]' 'API' 'host.power_on' (('host' 'xcpng02' '1139bfbc-c487-4311-8206-bbffe96ed6b1' 'OpaqueRef:426e950f-f926-490f-b598-328314aafbdc')))

Jul  8 02:58:04 xcpng01 xapi: [20200708T07:58:04.229Z|audit||53358 |Async.host.power_on R:e730dacdf348|audit] ('trackid=68849bbe6e0a22d9b0b024c21c2b6e36' 'LOCAL_SUPERUSER' 'root' 'ALLOWED' 'ERROR:INTERNAL_ERROR: [ (Failure \"The host failed to power on.\") ]' 'API' 'host.power_on' (('host' 'xcpng02' '1139bfbc-c487-4311-8206-bbffe96ed6b1' 'OpaqueRef:426e950f-f926-490f-b598-328314aafbdc')))

Jul  8 03:58:04 xcpng01 xapi: [20200708T08:58:04.897Z|audit||58846 |Async.host.power_on R:19f454d900b0|audit] ('trackid=68849bbe6e0a22d9b0b024c21c2b6e36' 'LOCAL_SUPERUSER' 'root' 'ALLOWED' 'ERROR:INTERNAL_ERROR: [ (Failure \"The host failed to power on.\") ]' 'API' 'host.power_on' (('host' 'xcpng02' '1139bfbc-c487-4311-8206-bbffe96ed6b1' 'OpaqueRef:426e950f-f926-490f-b598-328314aafbdc')))

Now going back in time to audit.log.[2-7].gz

fgrep Async.host.power_on /var/log/audit.log

Jul  8 10:58:09 xcpng01 xapi: [20200708T15:58:09.775Z|audit||104166 INET :::80|task.destroy D:b3c0abbbd938|audit] ('trackid=68849bbe6e0a22d9b0b024c21c2b6e36' 'LOCAL_SUPERUSER' 'root' 'ALLOWED' 'OK' 'API' 'task.destroy' (('self' 'Async.host.power_on' '3450e4eb-9a11-24ba-5e0c-699ff352028b' 'OpaqueRef:99fd01c3-535d-4334-bb92-c4cb4f84f16c')))

Jul  8 11:51:16 xcpng01 xapi: [20200708T16:51:16.956Z|audit||108793 UNIX /var/lib/xcp/xapi|task.cancel D:05f4e18101a6|audit] ('trackid=e49c5c3a24fed047e0aa1a3ed7b47ab3' 'LOCAL_SUPERUSER' 'root' 'ALLOWED' 'OK' 'API' 'task.cancel' (('task' 'Async.host.power_on' 'e1896255-fbec-76d6-c2f4-9c2829c1f72b' 'OpaqueRef:083c7658-c1e5-46d7-bf9c-3b809be635d6')))