Intel® vPro™ Technology

Enabling Dynamic Virtual Client Computing with Intel® vPro™ Technology

Client Virtualization

Basic Taxonomy
We now provide a view of the taxonomy of the basic virtualization approaches and their relation to one another, shown in Figure 2.

Figure 2: Client virtualization taxonomy

• Presentation Virtualization is a client-server architecture for executing applications within a user session that is hosted on a remote server by using a remote presentation protocol to display the session at the client.
• Application Virtualization is a client-side technology for executing applications within a protective sandbox designed to isolate and control the interactions of an application with other applications and the underlying OS.
• Device Virtualization is a class of technologies or techniques to service operational interactions (for example, discover, control, transfer, interrupt) and enable resource isolation, sharing, and functional extensibility of client devices.
• Machine Virtualization is based on a particular type or model of virtualization architecture and associated methodologies to support the abstraction of platform hardware to enable alternative computing models and resource partitioning, and to enable sharing across diverse hosted image types on a physical platform.
• Desktop Virtualization is a class of technologies where the entire desktop environment is hosted within a machine virtualization environment, typically accessed via remote desktop protocols.

Overview of Virtualization with Intel® vPro™ Technology
A platform, enabled with Intel vPro technology, is an advanced client platform that allows IT personnel to take advantage of hardware-assisted security and manageability capabilities that enhance a corporation's ability to manage and protect fixed and mobile PCs. With functionality built-in to hardware, Intel vPro technology enables out-of-band (OOB) manageability and down-the-wire security, even when the PC is powered off, unresponsive, or when the host agents are disabled. Along with leading ISV console solutions, Intel vPro technology improves manageability to reduce operational or administrative costs. In addition, hardware-enabled virtualization features in platforms with Intel vPro technology enable more robust, secure, and optimized virtualization usage models.

Platforms running Intel vPro technology support Intel® Virtualization Technology (Intel® VT) for IA-32 Intel® Architecture (Intel® VT-x) [3], Intel® Virtualization Technology (Intel® VT) for Directed I/O (Intel® VT-d) [4], Intel® Trusted Execution Technology (Intel® TXT) [5], and Intel® Active Management Technology (Intel® AMT) [6]; all of which can be combined to uniquely deliver next-generation, value-added client usage models. With the use of Intel VT-x and Intel VT-d, hardware acceleration and memory space protection can be achieved. With the use of Intel TXT, a solution can be verified prior to execution to prevent unwanted changes. Many usage models benefit from hardware-accelerated virtualization, hardware protection of memory, measured and verified code before it is executed, and OOB access to the physical platform or certain virtual machines (VMs). These technologies can be combined to support both industry standard Type 1 (hypervisor-based) virtual machine monitors (VMMs) and Type 2 (OS-hosted) VMMs [7], depending on the supported usage model.

Type 1 VMMs
For increased security and isolation, Type 1 VMMs ensure a sequestered execution environment for each VM. Isolation extends from the hypervisor through the VMs with which the end user interacts. The Intel TXT can ensure a trusted boot process to further reinforce Type 1 VMM, through a hardware-based chain of trust, to secure, launch, and validate the hypervisor and associated VMM components. Jointly, Type 1 VMMs and Intel TXT enable a secure and robust environment from boot to execution.

For Type 1 VMMs, physical machine hardware can be either directly mapped to a VM (that is, pass-through mode) or virtualized. In pass-through mode, the physical device is directly mapped to a single VM. The physical device's driver is loaded in the VM and will physically control the device in this mode; the VM is most typically a Windows XP* or Windows Vista* OS with native device driver support. The benefit of this mode is its uses of the underlying hardware device as it was intended to be used by the developers of the device and device driver. Therefore, this mode offers the best compatibility and performance. Theoretically, the device will function as if there is no virtualization layer, thereby optimizing performance and power management.

However, the main drawback with the pass-through mode is that the device is owned by a single VM and no other VM can access it. For some devices, this may not be a problem and may even be desired (as in the case of a wireless device) but for others, this mode of operation will be problematic. Graphics adapters are a good example of this drawback: if one of the VMs owns the graphics adapter, display by other VMs is problematic or is dependent on the VM that owns the graphics adapter. To put it succinctly, if one VM "owns" the graphics adapter, others cannot display.

If the other VMs have to display, they need to do it through an interface exposed by the owning VM. This could be in the form of a front-end/back-end driver setup (that is, a client/server setup of sorts) or a different technology altogether that has display-back capabilities similar to those of X-Windows*. The former has the added drawback of complexity and the latter has a negative performance impact on video and 3D playback and it may even impact 2D operations. Additionally, this extended device model makes the subsequent (non-owner) VMs dependent on the primary VM, and therefore may introduce other operational issues, if not designed and integrated properly.

Intel VT-d enhances the software-based isolation capabilities of direct-mapped devices to VMs by providing hardware-based memory partitioning, that is, protection domains. Intel VT-d also provides Direct Memory Access (DMA), or interrupt remapping and cache optimizations (for example, remapping structure or translation). These enhancements allow (predominantly) Type 1 I/O-based virtualization usages to improve isolation on the key operational vectors of security, performance, and reliability. The reader can refer to [4] for further details.

The alternative to the pass-through method for hardware assignment is that of virtualization. In this mode, hardware is assigned to a virtualization domain , also referred to as the root or parent OS partition. This virtualization domain or root partition, typically exports the device models to subsequent VMs. The root or parent partition has the physical device driver and exports a device model that may or may not match the underlying physical device (that is, an NE2000 Ethernet* card could be exported for a branded gigabit Ethernet adapter). By exporting a generic device, the VMM designer, IT shop, or OEM can better ensure device compatibility with a wide range of operating systems. However, such compatibility comes at the price of features and, potentially, usability. The benefits of exporting a native device model are to ensure full-feature support of the underlying device in VMs and also to ensure the user experience is not affected. However, these benefits are difficult to achieve without investment by the company that designed the native device. Furthermore, there may be performance implications as compared to the use of the pass-through mode.

Type 2 VMMs
Type 2 VMMs run within a host OS, typically Windows XP* or Windows Vista*, but Linux and other operating systems can also be supported. This reduces the isolation benefits that come with the use of Type 1 VMMs, but Type 2 VMMs are easier to adopt because they use the device drivers that are present in the host OS (similar to pass-through mode). A Type 2 VMM essentially turns the host OS into a "functionally analogous" root partition. Alternatively, the primary OS "owns" the devices and the VMM that runs (in Ring 0 mode) within the host OS accesses the devices through the device drivers or OS APIs. The VMMs will usually emulate or export generic device models as opposed to native ones, but there is no intrinsic reason for this.

In general, the degree of device isolation achieved currently by a Type 1 VMM is superior to a Type 2 VMM. In the Type 2 model, all hosted VMs are exposed to the same issues and constraints as the host OS: if the host is shut down, compromised, or impacted by faulty user invocations, then all VMs are also affected. Alternatively, the Type 1 model has significant benefits. As noted earlier, this model can support devices more easily as the host OS "owns" the device, so any device that has a driver can be utilized by the VMM and made available to all VMs (note that the VMM must be aware these devices and how to export them). There may also be usability benefits with the Type 2 versus Type 1 model. Because all VMs are contained within the host OS they can be exposed to the end-user simply as "applications," thereby blurring the lines of operating systems separation or independence.

A common requirement for both Type 1 and Type 2 models is the efficient sharing of platform device resources by concurrently running virtual machines or system images. While Intel broadly supports this requirement, the applicability of a hardware-based approach for device sharing should be motivated by usage, sharing, and performance requirements. In some usage scenarios, certain devices will not require sharing across multiple VMs, and/or alternatively, software-based methods may be more cost-effective, simpler to employ, and have no user-perceived performance implications. However, in cases of strict security requirements (for example, isolating user host-interface device invocations) or shared isochronous device communications, Intel supports the PCI Express* [9] specifications for hardware-based SRIOV [10] extensions. These enable virtualization and assignment of specific device functions to VMs for device sharing, as required by specific client virtualization usages and device types.

Next-generation virtualization usage models will combine these types of VMMs with streaming technologies to further enable remote management and delivery of OS and application images. The result will be a reduction in operational complexity in software deployment and image management. In the upcoming section, we present an emerging class of client computing usage models, which we refer to as Dynamic Virtual Computing (DVC). DVC embraces the merits of hardware and software virtualization technologies to deliver a flexible and rich computing platform, but integrates the additional Intel vPro technology hardware value propositions (that is, Intel AMT) to enable a more manageable and secure client virtualization platform.

Back to Top