Background
Intel provide Active Management Technology to allow out of band monitoring and management of machines, regardless of the state of the client OS.
The BMC / ME can be assigned its own static address, which should "just work".
It can also use DHCP, although there may be come complications. Before AMT 5, the BMC / ME had its own MAC address (one greater than the host MAC address) so could DHCP independently. However, since then, a single MAC address is used, so the BMC / ME and host must share a single IP address. It snoops on DHCP replies, and sets the ME IP address accordingly, so causes problems if VMs on the machine use DHCP. The BMC / ME will steal any traffic for its ports (623, 4899 and 16992 - 16994), making them unusable for the host, which may nevertheless try to use them.
It can also use a different VLAN if the NIC is a VTRUNK.
It is available on S3000AH, DQ965GFEKR (but access seems somewhat flaky - just keep trying), DQ965GFEKR (AMT 2), DDQ35JO (AMT 3), DQ45CB (AMT 5), DQ57TM (AMT 6), DQ67SW (AMT 7) and DQ77MK (AMT 8) systems.
If the host is not in S0, the ME may move to M1 or M3 'sleep' state after the Idle Timeout (in minutes up to 65535, unless 0), plus 90s, has expired. A 'nudge' can wake it from this state, e.g. "Intel AMT command", ping (if enabled), WebUI (? if not enabled ??), ARP command directed to an AMT port (? ARP request for IP address ??)
Initial Notes
See. intel-amt, quick start guide (pdf), Implementation and Reference Guide
Some code is available in /usr/groups/linux/extra-packages/intel-AMT/ such as lms from openamt to access the local ME.
Setup from BIOS
It should be possible to use Ctrl-P to manage the AMT setup and the ME. There may be alternative routes in, such as:
On a S3000AH, press F2, set "Advanced -> Management Configuration -> ENTER AMT BX SETUP -> Enable", save the settings and exit, and it should enter "Intel(R) Active Management Technology BIOS Extension v1.2.3.0000" on the next reboot.
On a DQ965* and DQ35* systems, press F2 and Cursor Right to "Intel(R) ME", and Return to "Enter Intel(R) Management Engine Password".
On a DQ77MK system press Ctrl-P and select "MEBx Login".
It will ask you for the password. The default is "admin" which has to be reset before remote management will work. Press Return to be prompted for the new PW. Passwords are 8 to 32 characters with at least one of each of: Upper Case Letter (A-Z), lower case letter (a-z), digit (0-9), "special" (!@#$%^&*). Clearing the password involves removing jumpers on the MB, so take care not to forget it. Use the "physical access" one with a stutter to meet the requirements
On a DQ965GFEKR there is a long delay before it comes up with a window saying that any changes need to be saved - press Return, and select "Intel(R) Active Management Technology Configuration".
[2011-09-06 fms] What if your new password is recognized by the local computer but not by the remote one? If the keyboard layout is anything other than US, note that some symbols may be on different keys (e.g. at least @#" between UK and US). When you redefine the password, the OS's keyboard driver is obviously not loaded, so what the BIOS receives may not be what you think you are typing. Then the password won't match the one you type in your client; and, because it isn't echoed, you won't even know. To check whether this is the cause of your problems, find a free-form text entry box in the BIOS and try typing your password in there to see what comes out. In the DQ965GF, for example, there is such an entry box in Setup / Intel ME / Intel AMT configuration / Computer Name.
Windows
Other than setting a "secure" password, the only required configuration (e.g. if wanting DHCP using a single MAC address) may be:
Set "Provisional Model" to "Small-Medium Business" (rather than the default Enterprise) to set it up manually. [fms:] On DQ57TM this is now called "Local" (rather than the default "Remote").
AMT 8
Select Intel(R) AMT Configuration and then
Select Network Setup -> Inter(R) ME Network Name Settings and set the names ($host-bmc) and set Dedicated.
Select Network Setup -> TCP/IP Settings -> Wired LAN IPV4 Configuration and set the addresses
Select Activate Network Access
AMT earlier
Set the Computer Name
Select TCP/IP Configuration to set the Domain Name, for Windows machines on VLAN 298 tick the DHCP Enable and you are then done with network configuration, in other cases untick DHCP Enable, set the IP address, Subnet Mask, Gateway Address, Preferred DNS Address and Alternate DNS Address.
Set "Provisional Model" to "Small-Medium Business" (rather than the default Enterprise) to set it up manually.
- The NIC can use VLAN tagging. On a DQ965* or DQ35* this appears not to be settable from the BIOS, so set it for the main VLAN, then use the HTTP server to reset it if needed - see details below.
On a S3000AH, check that "Serial Over Lan" and "IDE Redirect" are enabled. On a DQ*, check that "SOL/IDER Configuration" is set to "user Name and Password".
On a DQ965GFEKR select "Intel(R) Management Engine Configuration", and
Check "Manageability Feature' -> Intel(R) AMT"
Set "Turn On Intel(R) ME in Sleep States' -> Always/Enable" (this is believed to enable WWW access)
Check "Intel(R) ME After Power Failure -> Power On"
Set "Intel (R) ME WOL -> Enable" (in case WOL rather than WWW access is used)
Set "Idle Timeout -> 65535" (as 0 is no longer permitted) so that WOL works for 6.5 weeks (after what? Power on?).
When done:
On a S3000AH Exit (need to scroll down) and reboot. On a DQ965GFEKR, "Save and Commit Settings".
Using a different VLAN (servers in machine rooms)
The machines can using a single VLAN, or use a separately tagged VLAN for the AMT traffic. It is cleaner to keep the AMT BMC management traffic on a separate VLAN, but it requires addition configuration in the switch, making more opportunities for confusion and errors. It also appears that on at least some switches, enabling VLAN trunking disables fast spanning tree detection. As such the current suggestion is that servers in machine rooms use VLAN tagging, whereas user Work Stations in offices use a single VLAN. The Class C subnets 128.232.2 and 128.232.107 are used for $host-bmc and $host.bmc.
Enable VLAN and set which to use for the AMT (e.g. "Processor management" on 392). Under networking, enter the address (128.232.107.99), netmask (255.255.255.0) and default router (128.232.107.1).
Take the port down using HW (unplug it) or SW (mark it down). On the Cisco switch, enable VTRUNK and allow just the required VLAN (as clients don't VTRUNK prune).
conf interface FastEthernet0/1 switchport trunk native vlan 100 switchport mode trunk switchport trunk allowed vlan 100,392 (ctrl-Z) wr sh conf
use "switchport trunk allowed vlan add 392" to amend the current allowed VLANs
use "spanning-tree portfast trunk" if it warns that trunk mode disables portfast
some switches may need "switchport trunk encapsulation dot1q"
some switches require VLANs 1002-1005, so use "switchport trunk allowed vlan 100,392,1002-1005"
Re-enable the port.
Accessing (other than BIOS/POST at the console)
Access from VNC Viewer Plus (AMT 6+, on chip graphics)
If the machine has AMT 6 or later and uses the on chip graphics (see the hosts property BMC_vnc_plus), KVM access is possible using VNC Viewer Plus which requires a licence. Select "Connection Mode: Intel (R) AMT KVM" and "Encryption: None". If the machine does not use the on chip graphics, it may fail "Insufficient Permission to access" (as does bulova for reasons unknown) (most AMT 6) or "Unsupported or inactive display adapter" (bezier). If the machine is off and is not using on-chip graphics, connection may be possible, but it will disconnect when it turns on.
[fms:] If AMT access via the web browser works but you get that ambiguous "Insufficient permission to access" from VNC it may mean what it says, but it may also mean "I'm not telling you, but this hardware cannot run the VNC-based KVM". Even if the machine has AMT 6 or later. Even if the processor has on-chip graphics. Even if the BIOS lets you enable and disable the KVM options and set their permissions. The motherboard, chipset and processor ALL have to support AMT KVM for VNC+ to work. As for processors, only a few Core i5 and Core i7 (not Core i3) support AMT KVM and there is no easy way to tell which ones other than by consulting the following list. Just to show how unpredictable this is: the Sandy Bridge i5 2500K, which is in theory "slightly better" than the i5 2500 (ie has a higher-spec graphics subset, is unlocked and costs 10-20 pounds more) does not support VNC, even though the basic 2500 does. Summary: before spending hours trying to debug why it doesn't work, first check that the hardware actually supports it.
[sjm217:] If access to the KVM via VNC+ fails with "Unsupported or inactive display adapter" after boot, then adding "nomodeset" to the Linux command line may help (it did on ctsrd-slave2.sec). This can be achieved by setting: GRUB_CMDLINE_LINUX_DEFAULT="nomodeset" in /etc/default/grub for Ubuntu Server 12.04 LTS.
Access from web client on port 16992
If on a "core" Lab VLAN (but not the machine itself!), use http://$host.bmc:16992 (or http://$host-bmc:16992). If remote, use ssh tunneling, e.g. "ssh -N -L 8081:$host.bmc:16992 ssh-relay &", then connect to http://127.0.0.1:8081. For windows machines on VLAN 298 the same address is used by both the host and the bmc so access using http://$host.ad.cl.cam.ac.uk:16992
Access from a command line (amttool) on port 16994
The Linux command amttool (may need the amtterm and perl-LWP-UserAgent-Determined packages to be installed) can be used to get general (info) and network (netinfo: 2.5+ only) info, reset, powerup, powerdown, powercycle, and configure the network (netconf: 2.5+ only). Commands which cause the machine to start can take a "special" argument to determine the boot behaviour.
A useful shell procedure to call this, which only keeps the password in the local shell, is:
ato() { h="$1"; shift; case "$h" in *bmc*|*.*|"") : OK;; *) h="$h"-bmc;; esac; case "$AMT_PASSWORD" in '') read -p "AMT_PASSWORD: " -s AMT_PASSWORD; echo;; esac; AMT_PASSWORD=$AMT_PASSWORD amttool $h "$@"; }
Access to SoL (radmin, gamt, amtterm) on port 16994
The Windows tool Radmin Viewer 3 (uses port 4899), the Linux GUI gamt and the Linux command line amtterm can be used to connect from another machine.
Linux clients appear only to be able to access the serial line when Linux has enabled a TTY VC -- they cannot access it during POST etc.
Access to BIOS or GrUB SoL, or boot non std device
In radmin, right click on the machine, select "Intel(R) AMT" and then:
"BIOS Remote Control" to change the BIOS
"Startup Remote Control" to do a standard boot and interact with GrUB
"Network Boot..." to boot from the floppy or optical drive, or to boot from an ISO image on the local FS
the machine will immediately be reset, with access to the console in a new window.
On ramotswe (DQ35JO F11) and tywi (DQ35JO U9.04) a std GrUB configuration allow interaction. rhine (DQ35JO F10) does not.
If in use by another session it reports "Failed to communicate with the AMT library".
Client serial console setup
See "man amt-howto" for instructions on enabling the serial console in GrUB and running a getty (ttyS2 is ttyS1 -- it doesn't have a 'normal' serial port I/O and IRQ: "ttyS1 at I/O 0xe1c0 (irq = 17)")