Power on function
I also found the "xe secret-create value=my-password" to produce the UUID in the doc.
Now iLO is configured on the master for both of my hosts.
I am unable to kill/cancel the previous power on attempt from XO web.
Async.host.power_on (on xcpng01) 0%
Is there a way to clear this?
Restart the toolstack on the master
Restarting the toolstack from XO or XCP-ng didn't clear it.
I'm manually powering up host 2 to migrate all VMs and change the pool master so I can reboot host1.
The unresolved task disappeared once host2 became available.
Now that host1 is powered off.
Parameters seem ok.
power-on-mode ( RO): iLO
power-on-config (MRO): power_on_ip: 192.168.1.44; power_on_user: Administrator; power_on_password_secret: 94171423-9ac2-beac-6b87-81699a0a7de6
xe host-power-on host=cdb42b94-7ec6-47b4-aaef-d4c52f6bd7b3
The cursor sits at column 1 after the newline from the command and never times out.
I know this isn't an XO problem, but in case somebody else gets this far...
From the xensource.log
May 14 11:06:45 xcpng02 xapi: [ info||5026 UNIX /var/lib/xcp/xapi||cli] xe host-power-on host=cdb42b94-7ec6-47b4-aaef-d4c52f6bd7b3 username=root password=(omitted) May 14 11:06:45 xcpng02 xapi: [ info||5026 UNIX /var/lib/xcp/xapi|session.login_with_password D:880acf326f2a|xapi] Session.create trackid=981ff975a6b71268bf97af6cf52b6c96 pool=false uname=root originator=cli is_local_superuser=true auth_user_sid= parent=trackid=9834f5af41c964e225f24279aefe4e49 May 14 11:06:45 xcpng02 xapi: [debug||5027 UNIX /var/lib/xcp/xapi||dummytaskhelper] task dispatch:pool.get_all D:f5013af2302b created by task D:880acf326f2a May 14 11:06:45 xcpng02 xapi: [debug||5026 UNIX /var/lib/xcp/xapi|host.power_on R:97714a622dc3|audit] Host.power_on: host = 'cdb42b94-7ec6-47b4-aaef-d4c52f6bd7b3 (xcpng01)' May 14 11:06:45 xcpng02 xapi: [debug||5029 UNIX /var/lib/xcp/xapi||dummytaskhelper] task dispatch:session.logout D:aea00adbbc6a created by task D:5292ea4ccdb8 May 14 11:06:45 xcpng02 xapi: [ info||5029 UNIX /var/lib/xcp/xapi|session.logout D:d10858afe74a|xapi] Session.destroy trackid=220441f1f21a1564d410801d86460ab1 May 14 11:06:45 xcpng02 xapi: [debug||5030 UNIX /var/lib/xcp/xapi||dummytaskhelper] task dispatch:session.slave_login D:2b34221718c5 created by task D:5292ea4ccdb8 May 14 11:06:45 xcpng02 xapi: [ info||5030 UNIX /var/lib/xcp/xapi|session.slave_login D:0072d08cd959|xapi] Session.create trackid=00f2456aa8d5ace26679a22fad62c265 pool=true uname= originator=xapi is_local_superuser=true auth_user_sid= parent=trackid=9834f5af41c964e225f24279aefe4e49
I'm going to have to get into tcpdump to find out what is going on there.
Are you trying to power on the master? If yes, it won't work, only the master can boot slaves.
@olivierlambert No, I'm on the master trying to power on the slave.
Async.host.power_on (on xcpnghost1) 0%
Persists in the web UI Tasks panel no matter what I do.
Shut down the entire environment and restarted.
No way to cancel it or delete it.
Are you sure it's not a XO refresh issue?
@olivierlambert It's been there since I played with power on function that failed.
Where is this task event stored? On the master? On XO?
How can I query it from a command line?
xe task-liston any pool member
Oh, that was too easy. There it is.
uuid ( RO) : e1896255-fbec-76d6-c2f4-9c2829c1f72b name-label ( RO): Async.host.power_on name-description ( RO): status ( RO): pending progress ( RO): 0.000 xe task-cancel uuid=e1896255-fbec-76d6-c2f4-9c2829c1f72b
Doesn't cancel it.
Okay and a toolstack restart on the master doesn't clean it?
@olivierlambert It did now but never did before
I wonder if it is because the same host the command was run against was the master at the time and is now. Perhaps server 2 as master previously failed when the command was on server 1.
Makes no sense to me. All good for now. Thank you.
@olivierlambert Nope, I didn't wait long enough. It's back.
uuid ( RO) : 4d1971f4-4895-78c8-2856-d679d457b75e name-label ( RO): Async.host.power_on name-description ( RO): status ( RO): pending progress ( RO): 0.000
It's not the same task (new UUID)
@olivierlambert correct, which tells me it has been added again by something else. XO? Where I initated the command originally?
You can check who did this in the
audit.logfile of your master
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')))
This is for task destroy, not a task creation.