Anyone have a soluttion to remote power on / off Intel AMT machine trough HA?
I find this debian tool:
LINK
4 Likes
I would love this functionality.
1 Like
***** FIRST *****
Do not use “amttool” as referenced in the original post. That tool is outdated. It used to work with early AMT systems that included SOAP API management. SOAP was deprecated (I think about AMT 6, don’t quote me on that) and AMT now only uses WSMAN API. No-one has gotten around to fixing amttool.
There are also WSMAN command line tools that are EXTREMELY complicated.
***** END *****
This is not an “integration” but makes AMT useable as a “switch”.
Note: Not all Intel systems have full AMT functionality. AMT is primarily targeted at Enterprise use cases for remote management. Look for the vPro sticker to be sure.
This is all from my lab that I manage.
I have a Linux server at YOURSERVERHOSTIP.
hassio in a VM, with the usual HA containers in the VM.
I have a few vPro systems.
I also have a few servers which use IPMI so I included that as well.
AMT shares the IP with the host IP and is alive whenever you have power+network.
To get AMT power control (vPro is the brand), this is the guts of what I did. There are probably better ways, like putting the meshcmd directly inside the container. You could also use the “command_on/off/state” directly to meshcmd, but I wanted it this way for other reasons, primarily so I could run it from the Linux shell when logged in to the server.
IPMI has a separate management interface/IP (usually on a separate management network, but it doesn’t have to be). In my case I have a naming convention of “host-rmm”, where “host” is the server hostname and “-rmm” refers to the “remote management module”.
There is also a bunch of stuff about where you might put the executables, like whether they are inside the containers or not, setting up remote authentication, etc. which is outside the scope of this response and documented elsewhere on the net.
Note: I have had instances where the AMT interface will go into some weird mode and stop responding or return Error 600. I have not root caused that.
The original poster had already “provisioned” AMT, probably by using CTL-P at the BIOS and going in to the AMT MEBX in the platform. You then look for “Enable Network Access” somewhere in there. This is documented elsewhere on the net.
Once is it provisioned, you can go to http://IP:16992/ which is the screenshot included in the original post.
You will need “meshcmd”. Calling the WSMAN API stuff is WAY too hard as mentioned above.
MeshCmd, also called “MeshCommand” is a open source command line tool that runs on both Windows and Linux and used to perform many tasks related to computer management.
For IPMI, you need “ipmitool” installed.
Then these scripts. They both return “on”/“off” on stdout which then goes back to HA.
You can test them with “/share/amtpower host” and it should tell you the power state.
[root@aumx share]$ cat /share/amtpower
#!/bin/bash
export AMT_PASSWORD='amtadminpassword' # No, this isn't my AMT admin password
node=$1
if [[ $2 == "on" ]]; then
/share/meshcmd amtpower --host $node --user admin --pass $AMT_PASSWORD --poweron 2>&1 > /dev/null
sleep 1
elif [[ $2 == "off" ]]; then
/share/meshcmd amtpower --host $node --user admin --pass $AMT_PASSWORD --poweroff 2>&1 > /dev/null
sleep 1
fi
/share/meshcmd amtpower --host $node --user admin --pass $AMT_PASSWORD | cut -f2 -d':' | sed 's/ //g' | sed 's/Power//' | sed 's/Soft//' # yes, there are neater ways to do this.
[root@aumx share]$ cat /share/ipmipower
#!/bin/bash
target=$1
action=$2
if [[ $action == "" ]]; then
action="status"
fi
n=$target
if [[ $n == "wsmex" ]]; then # a very old machine
auth="-U IPMIUSER -P IPMIPASSWORD"
else
auth="-I lanplus -C 17 -U IPMIUSER -P IPMIPASSWORD"
fi
if [[ $action == "on" || $action == "off" || $action == "reset" ]]; then
ipmitool $auth -H ${n}-rmm chassis power $action >/dev/null 2>&1
sleep 5
fi
ipmitool $auth -H ${n}-rmm chassis power status | sed "s/Chassis Power is //"
configuration.yaml
- switch:
name: quartz_sw
scan_interval: 120
command_on: ssh -i /config/.ssh/id_rsa hassio@YOURSERVERHOSTIP -o StrictHostKeyChecking=no "/share/amtpower quartz on"
command_off: ssh -i /config/.ssh/id_rsa hassio@YOURSERVERHOSTIP -o StrictHostKeyChecking=no "/share/amtpower quartz off"
command_state: ssh -i /config/.ssh/id_rsa hassio@YOURSERVERHOSTIP -o StrictHostKeyChecking=no "/share/amtpower quartz"
value_template: '{{ value == "on" }}'
unique_id: "quartz_sw"
icon: >
{% if value == "on" %} mdi:power-plug-outline
{% else %} mdi:power-plug-off-outline
{% endif %}
You don’t normally use AMT for turning machines off. You would normally use graceful shutdown commands.
AMT is good for turning machines back on again or resetting a frozen one.
AMT also supports many more use cases including full keyboard/video/mouse redirection functionality.
Thank you for your information, but such integration is not needed for me anymore. I’m using hass.agent now.
It was not an Intel NUC (some other type of mini PC) I was wrong about Intel AMT. It’s indeed not intended for normal shutdown.