But enterprise business is going to care about the out-of-band management, because at least the business I work for is looking to standardize on vPro hardware for the massive savings in power management and standardized remote control that is based in hardware, rather than an agent that can break, running on an OS that can break.
I have to admit that vPro feels more like a line item than a feature. By that, I mean that I've never encountered anything that's leveraged vPro to make my life easier as a SysAdmin. Now I've got a machine with vPro built in and I haven't the slightest clue what I could do to at least play with it.... I should get out more :D
vPro was ironically one of the features of this Helix that inched me closer to deciding to purchase it, though it wasn't vPro explicitly. Someone on the Xen-Users mailing list made a note that every machine he'd looked at recently that had VT-d capability also had vPro. The Helix's marketing materials certainly made a strong point about vPro capability, and a phone call to Lenovo helped me dig up the proper technical documentation to determine that the Helix does have VT-d support in its BIOS, Chipset, and Processor.
using vPro to remote control the bluescreen'd PC while the OS is halted, reboot it and go into the BIOS, and change the setting. All remotely, from 1000 miles away.
...really? Even on a Wi-Fi-only machine like the Helix? That's.... wow that's useful. I want that kind of stuff on my own machines... especially the fleet of immediate-family-owned computers that are more trouble to support than any enterprise machine I've been paid to lay my hands on :P
The reason I wanted VT-d support has to do with a bit of an epiphany that I had recently about the role of hypervisors in modern computing... I expect them to ultimately replace or supersede the role of firmware in pretty much every system we use. Xen, particularly with the existence of its XenARM branch, is moving this way. VT-d and AMD-Vi can facilitate this already---albeit not with the degree of reliability that enterprise standards require... yet---and more compliance with standards like SR- and MR-IOV will bring this to its full potential.
To illustrate, take the allure of VDI: Independent systems for each user, centrally managed with the ability to leverage datacenter-grade high availability and fault tolerance... but still subject to the same delivery restrictions of thin-client computing. Latency and bandwidth choke out the potential for true high-performance usage, and while server-grade processors pack extreme density per rack-unit of space, they lack the single-threaded performance of even modest desktop-grade chips. If instead of delivering only the video output, when a client connects we migrate the whole kit and caboodle directly to the machine in question and simply wholesale-expose the entire PCI bus to the guest OS. When the user shuts down or disconnects, we disconnect the PCI bus, and save state or migrate back into the datacenter instead.
Extending this to home computer use, I could migrate all of my machines off to my server instead of having to leave my desktop powered up all the time to get the functionality that I want. I could "lock" my desktop, "unlock" my Helix, and bam: I'm literally using the same computer. You or I might migrate to a local server, but one could see the average person migrating an OS into an AWS datacenter.
The allure is more grand for the case of ARM and Android. Lock your phone, throw it in a garbage disposal, whatever, then unlock your tablet: you're using the exact same OS that just "flew" over the WiFi, out of your pocket, and into the tablet.
I'm on a long tangent. Point is, it's a hell of a time to be a nerd :)