Many motherboards have integrated AMT. Moreover, all Thinkpads have AMT. With ATM it is possible to control power remotely. No matter what is the current laptop's state: on, off, ... it is possible to take control over it using AMT. Even OS kernel get panic you still can take control over it. Links: General info: http://linux.die.net/man/7/amt-howto [Open URL] Implementations: https://github.com/schnoddelbotz/amtc [Open URL] -- this one even has RPM packages. http://iranzo.github.io/blog/2015/05/01/intel-amt-on-linux-for-remote-control-slash-fencing/ [Open URL] This feature give us an ability to attach to Beaker any thinkpad as an fully automated instance. There is cmdline utility, that will allow extend Beaker's power control management very easy. Thanks.
We have some AMT-capable hardware in our lab here so this should be doable. I see there is a client "amttool" available in Fedora and EPEL (part of the "amtterm" package), that would be the best starting point.
Please keep in mind, that there are two version of AMT: $ amtc -5 for AMT 5.0 hosts -d for AMT 9.0+ hosts - use WS-Man/DASH For me it works only with AMT 9.0: AMT 9.0 $ amtc -d -R astepano POWERRESET astepano OS:noscan AMT:08 HTTP:200 OK OLD AMT: $ amtc -R astepano POWERRESET astepano OS:noscan AMT:16 HTTP:404 No error Maybe it is cool to have two power control scripts for each AMT versions. Please do timeout 10 sec.... just for case.... -t(imeout) in seconds, for amt and tcp scans [5] amtc has very useful debugging output : amtc -vvv -R astepano $ amtc -vvv -R astepano * About to connect() to astepano port 16992 (#0) * Trying 10.34.130.181... * Connected to astepano (10.34.130.181) port 16992 (#0) * Server auth using Digest with user 'admin' > POST /RemoteControlService HTTP/1.1 User-Agent: amtc (libcurl) Host: astepano:16992 Accept: */* SOAPAction: "http://schemas.intel.com/platform/client/RemoteControl/2004/01#RemoteControl" Content-Type: text/xml; charset=utf-8 Content-Length: 0 < HTTP/1.1 401 Unauthorized < WWW-Authenticate: Digest realm="Digest:0D1E0000000000000000000000000000", nonce="eyiuChAlAAC+/MewTZC0nz7jmJ+KyH1V",stale="false",qop="auth" < Content-Type: text/html < Server: Intel(R) Active Management Technology 9.0.31 < Content-Length: 689 < Connection: close < * Closing connection 0 * Issue another request to this URL: 'http://astepano:16992/RemoteControlService' * About to connect() to astepano port 16992 (#1) * Trying 10.34.130.181... * Connected to astepano (10.34.130.181) port 16992 (#1) * Server auth using Digest with user 'admin' > POST /RemoteControlService HTTP/1.1 Authorization: Digest username="admin", realm="Digest:0D1E0000000000000000000000000000", nonce="eyiuChAlAAC+/MewTZC0nz7jmJ+KyH1V", uri="/RemoteControlService", cnonce="ICAgICAgICAgICAgICAgICAgICAgICAgICA3MDM3NTc=", nc=00000001, qop=auth, response="022eb6836936f95506ca8dd42c185ec0" User-Agent: amtc (libcurl) Host: astepano:16992 Accept: */* SOAPAction: "http://schemas.intel.com/platform/client/RemoteControl/2004/01#RemoteControl" Content-Type: text/xml; charset=utf-8 Content-Length: 546 * upload completely sent off: 546 out of 546 bytes < HTTP/1.1 404 Not Found < Content-Type: text/html < Server: Intel(R) Active Management Technology 9.0.31 < Transfer-Encoding: chunked < Connection: close < * Closing connection 1 -POWERRESET astepano AMT:0016 HTTP:404 No error $ rpm -qi amtc Name : amtc Version : 0.8.5~alpha3 Release : 1.el7.centos Architecture: x86_64 Install Date: Thu 20 Aug 2015 05:18:12 PM CEST Group : Applications/System Size : 56624 License : CC BY 3.0 Signature : (none) Source RPM : amtc-0.8.5~alpha3-1.el7.centos.src.rpm Build Date : Tue 05 May 2015 12:17:15 AM CEST Build Host : localhost Relocations : (not relocatable) URL : https://github.com/schnoddelbotz/amtc Summary : Threaded remote power management commandline tool for intel vPro/AMT&DASH hosts Description : amtc is a simple command line tool, implemented in C, that can quickly control PCs that have out-of-band remote power management capabilities in the form of intel vPro/AMT or AMD DASH. amtc's key focus is not to support all SOAP operations AMT/DASH is aware of -- instead it concentrates only on vital OOB operations (on/off/reset/...). amtc can be combined with amtc-web to have a fluffy web GUI for power management tasks and power state logging/graphing. Combining amtc (or amtc-web) with cron makes scheduled power management.
Any progress? Intel AMT is quite popular now.
We are trying to add Thinkpad W541 Lenovo laptop to the Beaker. The only option right now is to power off the laptop by switching off the power with PDU and to power the laptop ON we have to use WAKE ON LAN. WAKE ON LAN is most difficult part as WOL does not support the routing. It means we have to place the laptop in the main lab in another building and not to our minilab. Having AMT support in Beaker would solve all these issues. Therefore I vote for adding this feature. Thanks a lot! Jirka
I have developed amtc Beaker agent. It's located here: http://git.app.eng.bos.redhat.com/git/kernel_perf_cpumem.git/tree/amtc
Hi Roman, could we add amtc Beaker agent to the Beaker upstream project? Thanks a lot! Jirka
Dear Jiri, I'm happy to include it, yet there are a few questions I haven't found answers yet: * I think currently our power scripts are not automatically tested, so not sure how we can make sure that these additions don't regress * we currently have no capacity of actively working on this to include the patch due to higher prioritised work * not sure how we deal with power script dependencies. It seems we ship power scripts the Beaker package does not exclusively depends upon (e.g. virsh). I guess step 1 would be to see how the labs team get it working. If that's without problems I'm happy to include it. Furthermore, I'll have a chat with Dan for input to my questions and the inclusion of the script. TL;DR: Happy to include it with the precaution that we're currently flat out with work and it'll take a bit of time.
Hi Roman, we are using this addition on 4 laptops on this Beaker server: https://beaker.cluster-qe.lab.eng.brq.redhat.com ad 1 - testing/regression concerns: So far there it works just fine - if there will be an issue I will fix it and I will try to get the fix to the upstream as well. ad 2 - no capacity of actively working on this It's done, I'm just asking to merge it to the upstream project under labcontroller/power-scripts/ directory ad 3 - power script dependencies Looking at https://github.com/beaker-project/beaker/tree/aec7458f5e93403f21e8f10550d5569324943a58/LabController/src/bkr/labcontroller/power-scripts the majority of the scripts have dependencies. IMHO, it would be sufficient to add the dependencies to the documentation. In this case, the user just needs to install "amtc" from http://git.app.eng.bos.redhat.com/git/kernel_perf_cpumem.git/tree/amtc There are pre-built binaries at https://github.com/schnoddelbotz/amtc/releases Thanks a lot! Jirka
Hello Jiri, I'd like to ask what is your current status on using the AMTC after ~1 year and if the feature would still be considered so highly.
https://gerrit.beaker-project.org/c/beaker/+/6632
It's might not be possible to get AMTC to Fedora/RHEL package distribution, what about AMTterm, could this satisfy your needs? - https://apps.fedoraproject.org/packages/amtterm
I will take a look into this. Possibly it can do
Hi Tomas, the current implementation using the amtc tool and this Beaker power script: http://git.app.eng.bos.redhat.com/git/kernel_perf_cpumem.git/tree/amtc is working great for us. We are using it in production for 18 months now and it's very reliable. We have around 10 notebooks on which we do kernel CI testing, running the Beaker jobs several times in a week. Just previous month we have added 3 new laptops (Lenovo T590, T490s and Carbon 7th generation) and there were no issues with the amtc. I have just tried to use amtterm and it's not working for me: $1minutetip --epel -n 1MT-RHEL-7.7-released $yum install --enablerepo="epel" amtterm $AMT_PASSWORD=<PASSWORD_REMOVED> amttool t580-mm.tpb.lab.eng.brq.redhat.com info ### AMT info on machine 't580-mm.tpb.lab.eng.brq.redhat.com' ### AMT version: 11.8.50 404 Not Found at /usr/bin/amttool line 242. Same for another laptop: AMT_PASSWORD=<PASSWORD_REMOVED> amttool t490s-mm.tpb.lab.eng.brq.redhat.com info ### AMT info on machine 't490s-mm.tpb.lab.eng.brq.redhat.com' ### AMT version: 12.0.40 404 Not Found at /usr/bin/amttool line 242. Has anyone used amtterm to remotely control power for AMT 9.0+ hosts? I have added Florian Weimer on Cc. @Florian - I have seen you have contributed to amtterm Fedora package. Were you able to use amtterm to remotely control power for AMT 9.0+ hosts? Thanks a lot! Jirka
(In reply to Jiri Hladky from comment #19) > @Florian - I have seen you have contributed to amtterm Fedora package. Were > you able to use amtterm to remotely control power for AMT 9.0+ hosts? My contribution was this: * Wed Feb 21 2018 Florian Weimer <fweimer> - 1.6-5 - Use %%{set_build_flags} to set both CFLAGS and LDFLAGS So it's purely a toolchain engineering/release engineering change. I have not actually run the package, sorry.
You're right Jiri, the tool won't work since the SOAP has been deprecated. I have found AMT which seems to be maintained, but I cannot see python-amt in EPEL - https://github.com/sdague/amt There is an option to go with Openwsman that Ironic uses to manage AMT machines (https://wiki.openstack.org/wiki/AMT_Driver) and that one is present in almost all distros actually. Martin, seems like if we go with Openwsman we could get rid of a lot of powerscripts that we manage and unify it under one. The python bindings are also a plus. What do you think? Jiri, I apologize for the inconvenience, but we need to find something that we can get on RHEL. Hope you understand. Do you have time to test Openwsman?
Hi Tomas, I have tried the following and it has worked: yum install openwsman-python3 yum install fence-agents-amt-ws https://github.com/ClusterLabs/fence-agents fence_amt_ws -a t580-mm.tpb.lab.eng.brq.redhat.com -o status -p <PASSWORD> Status: OFF So it seems to work. However, we have laptops in production used for the kernel CI testing. We cannot afford to stop using them until we develop a new solution. So how about re-enabling the amtc support for now and switch it to the new tooling once it's developed and stable? Thanks! Jirka
FYI - Michal Novacek has developed Ansible playbook to install amtc support to beaker lab controllers. Feel free to use it: https://gitlab.cee.redhat.com/clusterqe/lab/blob/CLUSTERQE-136/beaker/lab-controller/ansible/amt.yml