There are several key differences one must consider when using Intel Active Management Technology (Intel® AMT) features on a virtualized client. Those differences, along with Intel’s recommendations, are discussed in this article. It is important to understand those differences in order to adjust the IT processes when managing virtualized clients with Intel Active Management Technology. The discussion in this paper only applies to client virtualization solutions that support Intel AMT.
Intel® Active Management Technology (Intel® AMT) provides the capability for IT departments to manage client systems even when the PCs are powered down. When the client is virtualized there are differences in the way the client is managed with Intel AMT. It is important to note that virtualization, in this case, is limited to virtualization on a physical system. This does not apply to desktop virtualization which runs on a server. Client virtualization is generally discussed as being either Type 1 or Type 2. This article does not discuss the merits of either solution, or the merits of using virtualization on a client system. The purpose of this article is to provide insight into using Intel AMT on clients that are virtualized. Since Intel AMT is only available on Intel vPro Technology platforms, it should also be noted that this paper only applies to Intel vPro Technology capable platforms.
It is assumed that the decision to virtualize the client PCs has already been made and therfore no attempt is made to discuss the merits of client virtualization. Instead, this article focuses on the expected behavior and Best Known Methods for managing PCs with client virtualization.
Type 1 virtualization—this method includes a hypervisor layer between the operating system of the virtual machine(s) and the hardware. The hypervisor either provides virtual devices to the virtual machines (VMs), or devices are passed through directly to the VMs. There are significant differences in the management capabilities and processes involved with Type 1 virtualization, and therefore this paper will focus primarily on Type1virtualization.
Type 2 virtualization—this method does not utilize a hypervisor. There is a host operating system layer directly on the hardware. VMs are created as files and run on top of the host OS. Since there are few differences in manageability with Type 2 virtualization we will only touch on this briefly.
Figure 1. Comparison of an OS hosted platform (Type 2 on the left) and a Hypervisor (Type 1 shown on the right) which runs directly on the device hardware.
Type 1 Virtualization
The manageability challenges surrounding Type 1 virtualization are much greater than that of Type 2 virtualization. Type 1 hypervisors work on a relatively small set of hardware, as compared to an Operating System. The HCL (Hardware Compatibility List) may or may not include Intel vPro Technology capable systems. If Intel vPro Technology capable clients are not supported, then Intel AMT functionality is not available. In addition, the hypervisor may not have support for Intel AMT built into it which severely limits the Intel AMT functionality available to IT departments.
For the discussion of Type 1 virtualization, we will assume that the client system and the hypervisor both support Intel AMT, and that the Intel AMT hardware devices are passed through to one of the VMs. It is important to note here that Intel AMT cannot be virtualized and can only be associated with one “machine,” either the physical system or a single Virtual Machine. In addition, there will likely be other restrictions from the hypervisor supplier. For example, Citrix* XenClient* restricts which devices can be passed through to a VM when Intel AMT is passed through.
Each Virtual machine has its own IP address, MAC Address, and Host name. When Intel AMT pass-through is selected, for a particular VM, the IP address, the MAC address and host name of the VM and Intel AMT will be aligned. If not, the Intel AMT pass-through is not working correctly and Intel AMT will not function correctly. The Intel AMT drivers and the Intel Management and Security Software (IMSS) can be installed onto the VM once the Intel AMT pass-through option is enabled and the system is rebooted.
- Power States (S3/S4/S5) – Since Intel AMT resides on the physical machine, it is unaware of the power state of the VMs, even when Intel AMT is passed through to a particular VM. This has several side effects.
- While trying to manage the client system, the management console will only provide visibility into the power state of the physical system. The power state of the VMs is not known.
- Action taken from the management console applies to the platform, not the VM. Shutting down the system could cause the VMs to be powered off without saving data.
- If the platform is on, but the VM is powered off, the VM cannot be powered on from the management console. The console will see the platform is already on and VM can only be turned on from the client system.
- However, if KVM Remote Control is available, it can be used to control the VMs. This applies to any VM, both with and without Intel AMT pass-through.
- System Reboots – Rebooting the client system can also cause a loss of data in the VMs. In addition, unless automatic boot is enabled for a VM it will remain off when the system powers back on.
- SOL boot to BIOS – There is no difference in using this feature on a client with virtualization.
- SOL boot to CD/ISO/HDD – With Type 1 virtualization this Intel AMT capability does not provide IT with any practical benefit. This is because the VMs are not accessible without the hypervisor. Booting to another OS and using a repair utility is not a valid use case with Type 1 virtualization.
- Fast Call For Help functions normally with Type 1 virtualization.
- KVM Remote Control – Systems that support KVM Remote Control (a feature of Intel AMT systems with Intel Core vPro Processors and Integrated graphics) can take full advantage of this feature and provides IT with the best option to manage a virtualized client. With KVM Remote Control the following are all accessible by the remote KVM console:
- The system BIOS and Intel MEBX
- The boot process
- The hypervisor GUI
- Linux terminal window
- Managed VM
- Non-managed VMs
- BIOS Updates – Do not attempt to update the BIOS from within a Virtual Machine. Select an alternative method provided by the OEM.
Type 2 Virtualization
Type 2 virtualization utilizes a host OS, therefore, the manageability of the physical client system is not at all different from the non-virtualized PC. Intel AMT will function in the same way on a Type 2 virtualized client as it does on a non-virtualized client.
The Intel AMT driver and IMSS are installed on the host OS. Intel AMT functionality is only directed toward the host. The VMs have no knowledge of the Intel AMT features and Intel AMT features have no knowledge of the VMs.
In managing a Type 2 client, IT departments will need to be aware that they have no in-band or out-of-band control over the VMs. Therefore they are not able to determine the power state of a VM, or power it on or off. Care needs to be taken when powering off the client with Intel AMT since data could be lost if a VM is running and data is not saved.
However, on Intel vPro Technology client systems that support KVM Remote Control, IT personel can access the host OS and use KVM Remote Control to control the VMs. This is a significant advantage when the IT professional needs to remotely start, shutdown, save data, or repair the virtual machine’s OS.
With Serial Over LAN and IDE Redirection (SOL/IDER), the IT processional will have the same capability on the client as a non-virtualized system. Redirection can be used to repair the host Operating System. Unfortunately, SOL/IDER will not provide IT with the capability to repair the VMs.
The use of a Type 1 virtualization solution on client systems will require a different approach when it comes to client management with Intel AMT. To a lesser degree, there are also differences as will when Type 2 virtualization solutions are used.
In the future, IT professionals will need a method to detect the virtualization type used on a PC. Currently management consoles such as Symantec* Altiris* and Microsoft* ConfigMgr are not capable of detecting whether the client being managed is virtualized or not.