Virtual Machines and Virtualization

of Clusters and Data Centers

IMPLEMENTATION LEVELS OF VIRTUALIZATION
• Virtualization is a computer architecture technology by which multiple virtual machines
(VMs) are multiplexed in the same hardware machine.
• The purpose of a VM is to enhance resource sharing by many users and improve computer
performance in terms of resource utilization and application flexibility.
• Hardware resources (CPU, memory, I/O devices, etc.) or software resources (operating
system and software libraries) can be virtualized in various functional layers.
• Virtualization technology has seen a sharp increase in demand for distributed and cloud
computing.
• The idea is to separate the hardware from the software to yield better system efficiency.
• Similarly, virtualization techniques can be applied to enhance the use of compute engines,
networks, and storage.
• With sufficient storage, any computer platform can be installed in another host computer,
even if they use processors with different instruction sets and run with distinct operating
systems on the same hardware.
Levels of Virtualization Implementation
• A traditional computer runs with a host operating system specially tailored for its hardware
architecture, as shown in Figure 3.1(a).
• After virtualization, different user applications are managed by their respective operating
systems (guest OS) and can run on the same hardware, independent of the host OS. This
is achieved by adding a software layer, known as a virtualization layer, as illustrated in
Figure 3.1(b).
• This virtualization layer is known as a hypervisor or virtual machine monitor (VMM).
• The VMs are shown in the upper boxes, where applications run with their own guest OS
over the virtualized CPU, memory, and I/O resources.
• The main function of the software layer for virtualization is to virtualize the physical
hardware
of a host machine into virtual resources to be used by the VMs.
• The virtualization software creates the abstraction of VMs by interposing a virtualization
layer at various levels of a computer system.
• Common virtualization layers include the instruction set architecture (ISA) level, hardware
level,
□ Instruction Set Architecture Level
• ISA-level virtualization emulates one Instruction Set Architecture (ISA) on another (e.g., MIPS on x86).
• Instruction set emulation leads to virtual ISAs created on any hardware machine.
• The basic emulation method is through code interpretation. An interpreter program interprets the
source instructions into target instructions one by one. One source instruction may require tens or
hundreds of native target instructions to perform its function. This process is slow.
• For better performance, dynamic binary translation is desired.
• This approach translates basic blocks of dynamic source instructions to target instructions. The
basic blocks can also be extended to program traces or superblocks to increase translation
efficiency.
• Instruction set emulation requires binary translation and optimization.
• A virtual instruction set architecture (V-ISA) requires adding a processor-specific software
translation layer to the compiler.
□ Hardware Abstraction Level
• Hardware-level virtualization generates a virtual hardware environment for a VM.
• The process manages hardware through virtualization.
• The idea is to virtualize a computer’s resources, such as its processors, memory, and I/O devices.
The intention is to upgrade the hardware utilization rate by multiple users concurrently.
• This idea was implemented in IBM VM/370 in the 1960s.
• More recently, the Xen hypervisor has been applied to virtualize x86-based machines to run Linux
or other guest OS applications.

□ Operating System Level

• An abstraction layer between traditional OS and user applications.
• OS-level virtualization creates isolated containers on a single physical server and OS instances to
utilize the hardware and software in data centers. The containers behave like real servers.
• OS-level virtualization is commonly used in creating virtual hosting environments to allocate
hardware resources among a large number of mutually distrusting users.
• It is also used, to a lesser extent, in consolidating server hardware by moving services on
separate hosts into containers or VMs on one server.
For example, having many physical servers, each running a specific service (such as a web server,
database, etc.), we can combine these services onto one powerful server using containers (like
Docker)
or virtual machines (VMs).
□ Library Support Level
• Virtualization with library interfaces, controlling the communication link between applications and the
rest of the system through API hooks.
• The software tool WINE enables Windows apps to run on UNIX by virtualizing Windows APIs.
• Another example: vCUDA – VM applications access GPU acceleration through virtualized CUDA
libraries.
□ User-Application Level
• Virtualization at the application level virtualizes an application as a VM.
• On a traditional OS, an application runs as a process. Application-level virtualization is also known as
process-level virtualization. The most popular approach is to deploy high-level language (HLL) VMs.
• The virtualization layer sits as an application program on top of the operating system, and the layer
exports an abstraction of a VM that can run programs written and compiled to a particular abstract
machine.
• The Microsoft .NET CLR and Java Virtual Machine (JVM) are two good examples of VMs. Other forms
of application-level virtualization are known as application isolation, application sandboxing, or
application streaming.
• The process involves wrapping the application in a layer that is isolated from the host OS and other
applications. The result is an application that is much easier to distribute and remove from user
workstations.
• An example is, LANDesk application virtualization platform, which deploys software applications as
self-contained, executable files in an isolated environment without requiring installation, system
Relative Merits of Different Approaches
VMM Design Requirements and Providers
o VMM (Virtual Machine Monitor) is a software layer between physical hardware and operating systems. It
virtualizes hardware resources (CPU, memory, etc.) and enables multiple OSs to run simultaneously on
the same machine. It behaves like a traditional OS by managing resource access.
o The three core requirements for a VMM are:
1. It must provide a virtual environment nearly identical to the real hardware.
2. Programs should run with minimal performance loss.
3. The VMM must have full control over all hardware resources.
o Two exceptions are allowed:
• Resource availability differences, due to multiple VMs sharing hardware.
• Timing differences, because of VMM overhead and concurrent VMs.
o A good VMM must offer high efficiency.
o To improve speed, dynamic execution is used where frequently executed instructions run directly on the
hardware, bypassing the VMM.
o A VMM controls resources in three ways:
1. Allocates hardware resources to VMs.
2. Prevents unauthorized access to unassigned resources.
3. Can reclaim resources from VMs when needed.
o Not all CPUs support virtualization well. For example, x86 processors cannot trap some privileged
instructions, making it hard to implement a VMM.
o To overcome this, hardware-assisted virtualization is used, where processor design is modified to meet
VMM requirements efficiently.
Virtualization Support at the OS Level
• Cloud computing is emerging due to Virtual Machine (VM)
technology.
• It shifts hardware and staffing costs to third-party providers.
• Two key challenges in cloud computing are:
1. Dynamically scaling the number of physical machines or VMs
based on task requirements.
2. Slow VM instantiation, as new VMs are unaware of the current
application state.
• More research and development are needed to address these
challenges.
Why OS-Level Virtualization?
• Hardware-level VMs are slow to initialize and require large storage
due to repeated image content.
• Full virtualization suffers from low performance, low density, and may
require modifying the guest OS or hardware.
• OS-level virtualization addresses these issues by adding a
virtualization layer within the OS.
• It partitions physical resources to create isolated environments called
containers, VEs (Virtual Execution Environment), or VPSs (Virtual
Private System) to run on a single OS kernel.
• Each VE appears as a full server with its resources but shares the
same OS kernel. This is known as "single-OS image" virtualization.
• OS-level virtualization improves performance, efficiency, and
scalability in cloud environments.
Advantages of OS-Level Virtualization
1. Fast startup/shutdown, low resource use, high scalability.
2. State synchronization between VMs and the host OS – Allows better application state awareness.
3. Efficiency through resource sharing – VEs can access most host resources without modifying them.
4. Overcomes slow VM initialization and application state unawareness in cloud computing.

Disadvantages of OS-Level Virtualization

1. Same OS requirement – All VMs on a single container must belong to the same OS family (e.g.,
Windows-based VMs cannot run on a Linux host).
2. User preference issues – Some cloud users require different OS types, limiting flexibility.
3. Resource duplication problem – If each VM has a full copy of system resources, it leads to high storage and
performance costs.
Virtualization on Linux or Windows Platforms
• Most OS-level virtualization systems are based on Linux; Windows-based virtualization is still under research.
• The Linux kernel provides an abstraction layer, but new hardware may require a patched kernel for full
support.
• Many Linux platforms are flexible and not tied to a specific kernel, allowing multiple VMs to run on the same
hardware.
• Tools like Linux vServer and OpenVZ enable Linux platforms to support virtualization.
• FVM (Feather-weight Virtual Machine) is a Windows-specific OS-level virtualization tool designed for the
Windows NT platform.
• Table 3.3 and Example 3.1 provide summaries and illustrations of these tools in action.
Example 3.1: Virtualization Support on the Linux Platform: OpenVZ
• OpenVZ is an open-source container-based virtualization tool for Linux.
• It modifies the Linux kernel to support:
1. Virtual environments (VPS) – Each VPS functions like an independent Linux server with its own processes,
users, and
virtual devices.
2. Resource management – Controls CPU, disk space, and memory allocation.
3. Checkpointing and live migration – Saves VM state to a file for quick transfer and restoration on another
machine.
Resource Management in OpenVZ:
o Two-level disk allocation:
■ First level: Admin allocates disk space for VMs.
■ Second level: VM admin assigns disk space to users.
o Two-level CPU scheduling:
■ First level: OpenVZ decides VM priority.
■ Second level: Standard Linux CPU scheduler manages tasks within the VM.
o 20+ resource control parameters ensure optimized VM usage.
Middleware Support for Virtualization
■ Library-level virtualization is also known as user-level Application Binary Interface (ABI) or API emulation.
■ This type of virtualization can create execution environments for running alien programs on a platform rather
than creating a VM to run the entire operating system.
■ API call interception and remapping are the key functions performed.
■ This section provides an overview of several library-level virtualization systems: namely the Windows Application
Binary Interface (WABI), lxrun, WINE, Visual MainWin, and vCUDA, which are summarized in Table 3.4.
VIRTUALIZATION STRUCTURES/TOOLS AND MECHANISMS
■ Figure 3.1 shows the architectures of a machine before and after virtualization.
■ Before virtualization, the operating system managed the hardware.
■ After virtualization, a virtualization layer is inserted between the hardware and the operating system.
■ This virtualization layer is responsible for converting portions of the real hardware into virtual hardware.
■ Depending on the position of the virtualization layer, there are three typical classes of VM architectures, namely
o Hypervisor-Based Virtualization (also known as Virtual Machine Monitor (VMM)) architecture,
o Paravirtualization, and
o Host-based virtualization.
Hypervisor and Xen Architecture
■ The hypervisor supports hardware-level virtualization on bare metal devices like CPU, memory, disk and
network interfaces.
■ The hypervisor software sits directly between the physical hardware and its OS. This virtualization layer is
referred to as either the VMM or the hypervisor.
■ The hypervisor provides hypercalls for the guest OSes and applications.
■ Depending on the functionality, a hypervisor can assume a micro-kernel architecture like Microsoft Hyper-V Or
a monolithic hypervisor architecture like the VMware ESX for server virtualization.
■ A micro-kernel hypervisor includes only basic and unchanging functions (such as physical memory
management and processor scheduling). The device drivers and other changeable components are outside the
hypervisor.
■ A monolithic hypervisor implements all functions, including device drivers.
■ The size of the hypervisor code of a micro-kernel hypervisor is smaller than monolithic hypervisor.
The Xen Architecture
• Xen is an open-source microkernel hypervisor program developed by Cambridge University, that separates the
policy (handled by Domain 0) from mechanism (handled by Xen).
• Xen does not include any device drivers natively.
• This mechanism provides guest OS can have direct access to the physical devices.
• As the number of vendors is in the process of developing commercial Xen hypervisors, among them are Citrix
XenServer and Oracle VM.
• The core components of a Xen system are:

Components Description
Hypervisor Core virtualization layer between hardware and OS.
Kernel Supports guest OS execution
Applications Runs on guest OS instances
 Xen Domain Structure

• The guest OS, which has control ability, is called Domain 0, and the others are called Domain U.
• Domain 0 is a privileged guest OS of Xen. It is first loaded when Xen boots without any file system drivers
available. Domain 0 is designed to access hardware directly and manage devices.
• Therefore, Domain 0 is to allocate and map hardware resources for the guest domains (the Domain U domains).
• For example, Xen is based on Linux and its security level is C2.
• Domain 0 manages other VMs implemented on same host.
• If Domain 0 is compromised, the hacker can control the entire system. So, in VM system, security policies are
needed to improve the security of Domain 0.
• Domain 0 allows users to create, copy, save, read, modify, share, migrate, and roll back VMs as easily as
manipulating a file.
Binary Translation with Full Virtualization
• Depending on implementation technologies, hardware virtualization can be classified into two categories:
full virtualization and host-based virtualization.
• Full virtualization does not need to modify the host OS. It relies on binary translation to trap and to virtualize the
execution of certain sensitive, nonvirtualizable instructions. The guest OSes and their applications consist of
noncritical and critical instructions.
• In a host-based system, both a host OS and a guest OS are used.
• A virtualization software layer is built between the host OS and guest OS.

Full Virtualization
• With full virtualization, noncritical instructions run on the hardware directly while critical instructions are
discovered and replaced with traps into the VMM to be emulated by software.
• Both hypervisor and VMM approaches are considered full virtualization.
• Noncritical instructions do not control hardware or threaten the security of the system, but critical instructions do.
• Running noncritical instructions on hardware not only promotes efficiency, but also ensures system security.
Binary Translation of Guest OS Requests Using a VMM
• Binary translation is a technique used by VMware and others for full virtualization.
• The VMM is placed at Ring 0, while the guest OS runs at Ring 1.
• The VMM scans the instruction stream and traps privileged and sensitive instructions.
• These instructions are emulated by the VMM using binary translation, making the guest OS unaware of
virtualization.
• Full virtualization combines binary translation with direct execution.
• Performance overhead exists, especially for I/O- heavy tasks.
• Code cache improves speed but increases memory usage.
• Full virtualization performance on x86 architecture reaches about 80% to 97% of native host performance.
Host-Based Virtualization
• Host-based VM architecture places the virtualization layer on top of the host OS, which controls hardware.
• Guest OSes run above this layer; some applications may run directly on the host.
Pros:
o Easy to install without modifying the host OS.
o Leverages host OS drivers, simplifying deployment.
Cons:
o Lower performance due to multiple layers (four-layer hardware access).
o Requires binary translation if the guest OS ISA differs from the hardware.
• Offers flexibility, but not ideal for performance-heavy tasks.
Para-Virtualization with Compiler Support
• Para-virtualization requires modification of guest operating systems.
• A para-virtualized VM provides special APIs requiring substantial OS
modifications in user applications.
• Performance degradation is a critical issue in a virtualized system. No
one wants to use a VM if it is much slower than using a physical
machine.
• The virtualization layer can be inserted at different positions in a
machine software stack.
• Para-virtualization reduces virtualization overhead, and thus improves
performance by modifying only the guest OS kernel.
• Figure 3.7 illustrates the concept of a para-virtualized VM architecture.
• The guest operating systems are para-virtualized. An intelligent
compiler assists them in replacing the nonvirtualizable OS instructions
by hypercalls as illustrated in Figure 3.8.
• The traditional x86 processor offers four instruction execution rings:
Rings 0, 1, 2, and 3. The lower the ring number, the higher the privilege
of instruction being executed.
• The OS is responsible for managing the hardware and the privileged
instructions to execute at Ring 0, while user-level applications run at
Ring 3.
Para-Virtualization Architecture
• When an x86 processor is virtualized, a virtualization layer is placed between hardware and the OS, operating at
ring 0.
• Para-virtualization replaces non-virtualizable instructions with hypercalls that communicate directly with the
hypervisor or VMM.
• When guest OS kernel is modified for virtualization, it can no longer run on the hardware directly.
• Compatibility and portability are affected, as unmodified OSes are not supported.
• Maintenance becomes complex due to the need for deep kernel modifications.
• Performance gains from para-virtualization vary with different workloads.
• Despite drawbacks, para-virtualization is easier and more practical than full virtualization.
• Full virtualization suffers from low performance due to binary translation.
• Many platforms like Xen, KVM, and VMware ESX adopt para-virtualization.

KVM (Kernel-Based VM)

• This is a Linux para-virtualization system—a part of the Linux version 2.6.20 kernel.
• Memory management and scheduling activities are carried out by the existing Linux kernel.
• The KVM does the rest, which makes it simpler than the hypervisor that controls the entire machine.
• KVM is a hardware-assisted para-virtualization tool, which improves performance and supports unmodified guest
OSes such as Windows, Linux, Solaris, and other UNIX variants.
Para-Virtualization with Compiler Support
•Para-virtualization handles sensitive instructions at compile time by modifying the guest OS, unlike full virtualization
which intercepts them at runtime.
• The guest OS kernel is altered to replace privileged instructions with hypercalls that interact directly with the hypervisor
or Virtual Machine Monitor (VMM).
• In para-virtualization, the guest OS runs at Ring 1, not Ring 0, which limits its ability to execute privileged instructions
directly.
• Hypercalls serve as safe interfaces that allow the guest OS to request services from the hypervisor securely and
efficiently.
• The modified OS emulates the original behavior using these hypercalls, maintaining functionality despite running at a
lower privilege level.
Example 3.3 VMware
• In systems ESX Server
like UNIX, where for Para-Virtualization
system calls use interrupts, Xen uses dedicated service routines to handle hypercalls
• VMware
similarly. ESX Server is a bare-metal hypervisor designed for x86 SMP servers,
providing direct access to hardware resources and full control over resource
management.
• ESX uses para-virtualization to enhance performance by allowing the VM kernel to
interact directly with hardware, bypassing the host operating system.
• The ESX server consists of four main components: a virtualization layer, a
resource manager, hardware interface components, and a service console.
• The virtualization layer (VMM) abstracts physical hardware like CPU, memory,
network, and disk controllers, assigning each VM its own virtual hardware set.
• The resource manager allocates and maps physical resources such as CPU,
memory, disk, and network bandwidth to the virtual hardware of each VM.
• Hardware interface components include device drivers and the VMware ESX
Server File System, enabling communication between hardware and the virtual
environment.
• The service console handles system booting, initiates the VMM and resource
manager, and provides an interface for system administrators to manage the
VIRTUALIZATION OF CPU, MEMORY, AND I/O DEVICES
• To support virtualization, processors such as x86 employ a special running mode and instructions, known as
hardware-assisted virtualization.
• VMM and guest OS run in different modes and all sensitive instructions of the guest OS and its applications are trapped in the
VMM.
• For the x86 architecture, Intel and AMD have proprietary technologies for hardware-assisted virtualization.
Hardware Support for Virtualization
• Modern operating systems and processors permit multiple processes to run simultaneously. If there is no protection mechanism in a
processor, all instructions from different processes will access the hardware directly and cause a system crash.
• All processors have at least two modes, user mode and supervisor mode, to ensure controlled access of critical hardware.
• Instructions running in supervisor mode are called privileged instructions. Other instructions are unprivileged instructions.
• In a virtualized environment, it is more difficult to make OSes and applications run correctly because there are more layers in the
machine stack.
• Example 3.4 discusses Intel’s hardware support approach.
• The VMware Workstation is a VM software suite for x86 and x86-64 computers. This software suite allows users to set up multiple x86
and x86-64 virtual computers and to use one or more of these VMs simultaneously with the host operating system. The VMware
Workstation assumes host-based virtualization.
• Xen is a hypervisor in IA-32, x86-64, Itanium, and PowerPC 970 hosts. Xen modifies Linux as the lowest and most privileged layer, or a
hypervisor. One or more guest OS can run on top of the hypervisor.
• KVM (Kernel-based Virtual Machine) is a Linux kernel virtualization infrastructure. KVM can support hardware-assisted virtualization
and paravirtualization by using the Intel VT-x or AMD-v and VirtIO framework, respectively.
• The VirtIO framework includes a paravirtual Ethernet card, a disk I/O controller, a balloon device for adjusting guest memory usage, and
a VGA graphics interface using VMware drivers.
Example 3.4 Hardware Support for Virtualization in the Intel x86 Processor
• Figure 3.10 provides an overview of intel’s full virtualization techniques.
• Intel provides hardware-assist technique to make virtualization easy and improve performance.
• Intel offers VT-i (for Itanium) and VT-x (for x86) adds a privileged mode(VMX Root Mode) and some instructions to
processors. This enhancement traps all sensitive instructions in the VMM automaticallly.
• EPT (Extended Page Tables) is used for memory virtualization, translating virtual addresses to physical ones
efficiently.
• For I/O virtualization, Intel uses VT-d (device assignment) and VT-c (I/O optimization) to boost performance and
control.
CPU Virtualization
• A Virtual Machine (VM) is a copy of a real computer system. Most of its instructions run directly on the host CPU, making it fast.
• Some important instructions (called privileged, control-sensitive, and behavior-sensitive) need special handling to keep the
system safe and correct.
• Privileged instructions execute in a privileged mode and will be trapped if executed outside this mode.
• Control-sensitive instructions attempt to change the configuration of resources used.
• Behavior-sensitive instructions have different behaviors depending on the configuration of resources, including the load and
store operations over the virtual memory.
• CPU architecture is virtualizable if it supports the ability to run the VM’s privileged and unprivileged instructions in the CPU’s
user mode while the VMM runs in supervisor mode.
• When privileged instructions includes control- and behavior-sensitive instructions of VM are executed, they are trapped in the
VMM. Then, VMM acts as a unified mediator for hardware access from different VMs to guarantee the correctness and stability
of the whole system.
• Not all CPU architectures are virtualizable.
• RISC CPU architectures can be naturally virtualized because all control- and behavior-sensitive instructions are privileged
instructions.
• x86 CPU architectures are not designed to support virtualization because 10 sensitive instructions, such as SGDT and SMSW,
are not privileged instructions. When these instructions execute in virtualization, they cannot be trapped in the VMM.
• On UNIX-like system, a system call triggers 80h interrupt and passes control to the OS kernel. The interrupt handler in the kernel
is then invoked to process the system call.
• On a paravirtualization system such as Xen, a system call in the guest OS first triggers 80h interrupt normally and 82h interrupt
in the hypervisor is triggered. When the hypervisor completes its task for the guest OS system call, it passes control back to the
guest OS kernel and the guest OS kernel may also invoke the hypercall while it’s running. Paravirtualization of a CPU,
unmodified applications run in the VM, it causes a small performance penalty.
Hardware-Assisted CPU Virtualization
• Hardware-assisted virtualization makes virtualization easier by avoiding the complex steps of full or
paravirtualization.
• Intel and AMD added a new privilege mode level (often called Ring -1) to x86 CPUs, allowing the hypervisor to run
below the operating system.
• The OS can still run in Ring 0, while the hypervisor traps all privileged and sensitive instructions automatically.
• This technique removes the difficulty of implementing binary translation of full virtualization and allows operating
system to run in virtual machines without modification.
Example 3.5 Intel Hardware-Assisted CPU Virtualization
• Although x86 processors aren’t designed for virtualization, they are still
widely used, so efforts like Intel VT-x help make them virtualizable.
• Intel’s VT-x uses a special VMX Root Mode (a hardware privilege level)
and adds new instructions to manage VMs and save CPU state.
• Popular hypervisors like Xen, VMware, and Microsoft Virtual PC use this
VT-x technology.
• While hardware-assisted virtualization is efficient, since the transition
from the hypervisor to the guest OS incurs high overhead switches
between processor modes, it sometimes cannot outperform binary
translation.
• Virtualization systems such as VMware use a hybrid approach by
combining hardware and software methods.(i.e., few tasks are offloaded
to the hardware but the rest still done in software.
• Also, para-virtualization and hardware-assisted virtualization can be
combined to improve the performance further.
Memory Virtualization
• Memory virtualization works like virtual memory in modern OS, but in a virtual environment, memory must be
shared and managed between multiple VMs.
• In traditional execution environment, the operating system maintains mappings of virtual memory to machine
memory using page tables, which is a one-stage mapping.
• All modern x86 CPUs include a memory management unit (MMU) and a translation lookaside buffer (TLB) to
optimize virtual memory performance.
• In virtual execution environment, it uses two-stage mapping: the guest OS maps virtual to physical memory,
and the VMM maps physical to machine memory.
• The guest OS handles its own memory mapping, but it can’t access real machine memory directly—the VMM
manages this.
• Figure 3.12 shows the two-level memory mapping procedure.
• Each page table of the guest OSes has a separate page table in VMM, the VMM page table is called the
shadow page table.
• Nested page tables add another layer of indirection to virtual memory.
• The MMU handles virtual-to-physical translations by the OS. Then the physical memory addresses are
translated to machine addresses using another set of page tables defined by the hypervisor.
• Since modern operating systems maintain a set of page tables for every process, the shadow page tables will
get flooded. Then, the performance overhead and cost of memory will be very high.
• VMware uses shadow page tables to perform virtual-memory-to-machine-memory address translation.
• Processors use TLB hardware to map the virtual memory directly to the machine memory to avoid the two
levels of translation on every access.
• When guest OS changes the virtual memory to a physical memory mapping, the VMM updates the shadow
page tables to enable a direct lookup.
• AMD's Barcelona processors introduced nested paging in 2007.
Example 3.6 Extended Page Table by Intel for Memory
Virtualization

• Intel created Extended Page Tables (EPT) to improve the

slow performance of software-based shadow page tables
in memory virtualization.
• EPT is a hardware-based solution that works with four-level
page tables and improves translation speed.
• Intel also introduced Virtual Processor ID (VPID) to enhance
TLB usage, reducing the need to flush it during VM switches.
• When translating a virtual address, the CPU first checks the
EPT TLB. If it’s not found, it checks the EPT page tables.
• If the needed translation isn’t available, an EPT violation
occurs, and the system handles it.
• The full address translation may require up to 20 memory
accesses, which can be slow.
• To reduce this delay, Intel enlarged the EPT TLB, helping to
cache more entries and improve overall performance.
I/O Virtualization
• I/O virtualization involves managing routing of I/O requests
between virtual devices and the shared physical hardware.
• There are three main methods: full device emulation,
para-virtualization, and direct I/O.
Full device emulation:
• Full device emulation is the first approach for I/O virtualization.
• It uses software in the VMM to act as a real devices, but it’s slow
due to heavy software processing.
• All functions of a device are replicated in software. This software
is located in the VMM and acts as a virtual device.
• The I/O access requests of the guest OS are trapped in the VMM
which interacts with the I/O devices. The full device emulation
approach is shown in Figure 3.14.

Para-virtualization:
• Splits drivers: Frontend in the guest VM and the backend in the host. They communicate through shared memory, improving
speed but increasing CPU usage.
• Hardware device can be shared by multiple VMs that run concurrently. However, software emulation runs much slower than the
hardware it emulates.
• The para-virtualization method of I/O virtualization is used in Xen. It is also known as split driver model consisting of a frontend
driver and a backend driver.
• The frontend driver is running in Domain U and the backend driver is running in Domain 0. They interact with each other via a
block of shared memory.
• The frontend driver manages I/O requests of guest OSes and the backend driver is responsible for managing real I/O devices
and multiplexing the I/O data of different VMs.
• Para-I/O-virtualization achieves better device performance than full device emulation, it comes with a higher CPU overhead.
Direct I/O:
• VMs access hardware directly, offering near-native performance but poses risks like system crashes during
resource reallocation.
• Intel VT-d helps secure I/O by remapping DMA and interrupts, supporting different guest OS types.
• The architecture of VT-d provides flexibility to support multiple usage models that may run unmodified,
special-purpose, or “virtualization-aware” guest Oses.
• Self-Virtualized I/O (SV-IO) uses multiple CPU cores to handle I/O tasks. It provides virtual devices and APIs to
VMs via Virtual Interfaces (VIFs) with message queues for communication.
• SV-IO defines one virtual interface (VIF) for every kind of virtualized I/O device, such as virtual network
interfaces, virtual block devices (disk), virtual camera devices, and others.
• The guest OS interacts with VIFs via VIF device drivers. Each VIF consists of two message queues. One is for
outgoing messages to the devices and the other is for incoming messages from the devices.
• Each VIF has a unique ID for identifying it in SV-IO.
Example 3.7 VMware Workstation for I/O
Virtualization
• VMware Workstation runs as an application and
uses full device emulation for I/O virtualization.
• It uses VMApp (application) and VMDriver (host
driver) to switch control between the host OS and
the VMM, which runs directly on hardware.
• The virtual NIC emulates the AMD Lance
Am79C970A network controller.
• The guest OS interacts with the virtual NIC using
virtual I/O ports. Each access is handled by
VMApp and passed to the VMNet driver.
• The VMNet driver sends packets through the host
NIC. After sending, a virtual interrupt notifies the
guest OS.
• Packet reception works in the reverse direction,
completing the emulated I/O communication.
Virtualization in Multi-Core Processors
• Virtualizing multi-core processors is more complex than virtualizing uni-core processors.
• Multi-core processors improve performance by integrating multiple processor cores in a single chip, multi-core virtualization
raised new challenges for architects, system designers, and programmers.
• Two main challenges:
1. Parallelizing application programs to use all cores effectively.
2. software must explicitly assign tasks to cores, which is complex.
• Include new programming models, languages, and libraries for parallel programming and scheduling algorithms for resource
management, to solve first challenge.
• Another issue called dynamic heterogeneity arises as fat CPU cores and thin GPU cores are integrated on the same chip,
adding more complexity.
• The dynamic heterogeneity of hardware infrastructure comes from less reliable transistors and increased complexity in
transistor use.

Physical versus Virtual Processor Cores

• Wells et al. introduced a multicore virtualization technique to provide
hardware designers with an abstraction of the underlying processor core
details.
• This method helps reduce the complexity and inefficiency of managing
hardware resources through software.
• It is implemented below the Instruction Set Architecture (ISA), ensuring
that it works independently of and without modifications to the operating
system or hypervisor.
• The technique allows software-visible virtual CPUs (VCPUs) moving from
one core to another and temporarily suspended execution of a VCPU
when there are no appropriate cores on which it can run(Figure 3.16).
Virtual Hierarchy
• Many-core CMPs support , where multiple workloads run
on separate core clusters simultaneously, improving performance and
isolation compared to time-sharing.
• Virtual hierarchies, proposed by Marty and Hill, dynamically overlay
cache and coherence structures over physical cores, adapting to
workload needs for better efficiency.
• The first level of the virtual hierarchy keeps data close to cores, reduces
access time, and isolates workloads. If the required data is not found at
this level, it accesses the second level, known as the L2 cache.
• In Figure 3.17(a), different workloads (database, web server,
middleware) are assigned to specific VM clusters, ensuring separation
and optimized cache use.
• Figure 3.17(b) shows that each VM operates independently at the first
level, while the second level maintains shared memory, allowing
dynamic resource adjustment and efficient virtualization.
• This approach benefits both multi-VM systems and single-OS
environments, supporting better performance and resource
management.

Note:
 VIRTUAL CLUSTERS AND RESOURCE MANAGEMENT
• A physical cluster is a collection of servers (physical machines) interconnected by a physical network such as a LAN.
• Unlike physical clusters, which consist of interconnected physical servers, virtual clusters are formed by grouping virtual
machines (VMs) across physical hosts using a virtual network.
• Three critical design issues of virtual clusters: live migration of VMs, memory and file migrations, and dynamic deployment of virtual
clusters.
• Traditional VM setup often requires manual configuration, which can lead to inefficiencies like overloading or underutilization
when scaling.
• Example - Amazon EC2 offers flexible, on-demand virtual computing, allowing users to create and manage VMs easily,
demonstrating the potential of elastic cloud resources.
• Platforms like XenServer and VMware ESX Server support bridging mode, enabling VMs to behave like standalone hosts and
communicate through virtual network interfaces automatically.
Physical versus Virtual Clusters
• Virtual clusters are built with VMs installed at distributed servers from one or more physical clusters. The VMs in a virtual
cluster are interconnected logically by a virtual network across several physical networks.
• Figure 3.18 illustrates the concepts of virtual clusters and physical clusters. Each virtual cluster is formed with physical
machines or a VM hosted by multiple physical clusters. The virtual cluster boundaries are shown as distinct boundaries.
• The provisioning of VMs to a virtual cluster is done dynamically with the following properties:
i. Virtual cluster nodes can be physical or virtual machines. Multiple VMs with different OSes can be deployed on the
same physical node.
ii. A VM runs with a guest OS, often different from the host OS that manages the physical machine's resources.
iii. VMs is to consolidate multiple functionalities on same server, enhancing server utilization and application flexibility.
iv. VMs can be replicated on multiple servers to enable distributed parallelism, fault tolerance, and disaster recovery.
v. The size of a virtual cluster can grow or shrink dynamically, like an overlay network in a P2P system.
vi. Failure of a physical node may affect its VMs, but VM failure doesn’t affect the host system.
• System virtualization effectively manages VMs running on a mass physical computing nodes (also called virtual
clusters) and consequently builds a high-performance virtualized computing environment. This involves virtual
cluster deployment, monitoring and management over large-scale clusters, as well as resource scheduling, load
balancing, server consolidation, fault tolerance, and other techniques.
• The different node colors in Figure 3.18 refer to different virtual clusters. In a virtual cluster system, it is quite
important to store a large number of VM images efficiently.
• Three physical clusters are shown on the left side of Figure 3.18. Four virtual clusters are created on the right,
over the physical clusters.
• The physical machines are also called host systems, whereas VMs as guest systems. The host and guest
systems may run with different operating systems.
• Each VM can be installed on a remote server or replicated on multiple servers belonging to the same or different
physical clusters.
• The boundary of a virtual cluster can change as VM nodes are added, removed, or migrated dynamically over
time.
• Figure 3.19 shows the concept of a virtual cluster based on application partitioning or customization.
• The different colors in the figure represent the nodes in different virtual clusters.
• To manage many VM images efficiently, it is important to store them smartly to save space and resources.
• Template VMs are used, where common software like operating systems and programming libraries are preinstalled.
• Users can create their own VMs by copying from these templates and then adding their specific libraries and
applications.
• This method allows faster setup and easier management of new OS instances without starting from scratch.
Fast Deployment and Effective Scheduling
• Fast Deployment: The system should quickly install all the needed software (like the operating system, libraries, and apps)
onto physical computers in the cluster. It should also easily switch from one user’ s virtual setup to another’ s so that when
someone finishes using it, the system can immediately free up those resources for others.
• Green Computing Focus: Previous efforts to save energy mostly looked at single computers, not the entire group of
computers (cluster). So, even if one machine saves power, the whole cluster might still waste energy. We need solutions that
work across the whole system.
• Problems with VM Migration: While moving virtual machines (VMs) between computers helps manage work better, it can
cause delays and extra work for the system. If done too much or badly, it can slow everything down and lower the system’ s
quality.

• Need for Smart Migration: To save energy without hurting performance, the system must have smart plans for when and how
to move VMs. Random or frequent migrations without planning can cause more problems than benefits.
• Load Balancing with Virtualization: The system should automatically adjust itself by looking at how busy it is or how many
users are logged in. If it’ s very busy, it should add more resources; if it’ s quiet, it should reduce them. This keeps the
system running smoothly and saves power.

• Better VM Placement: The system should carefully decide which physical machine should run which virtual machine. If the
load becomes uneven (some computers are too busy, others idle), it should move VMs smartly to balance the work and keep
everything fast and efficient.
High-Performance Virtual Storage
• Template VMs for Fast Deployment and Disk Space Management
Template VMs are ready-made virtual machines (with the OS and basic settings installed) stored across multiple physical servers. Instead of
creating a new VM from scratch each time, users can quickly customize a template, saving time. Also, templates avoid wasting disk space
because common files are shared rather than copied separately for each VM, reducing duplication.
• Using Hash Values for Storage Efficiency
Each block of data in storage can be assigned a unique "hash value". By comparing hash values, the system can quickly identify what data has
changed, what is duplicated, and what is unique for each user. This makes it easier to manage storage and track what specific modifications
each user made, without scanning the whole data every time.
• VM Deployment Steps with Templates
Deploying a virtual machine involves several steps: preparing its disk image (the virtual hard drive), setting up configurations (like memory, CPU,
and network settings), choosing where to run the VM (in which physical node), and finally starting it. Templates simplify this because the OS and
basic setup are already done, making the whole deployment process much faster.
• Copy-on-Write (COW) for Saving Disk Space and Time
Instead of making full copies of large VM images for every new user, the "Copy-on-Write" (COW) technique is used. In COW, only the changes
made by the user are saved separately in small files. The rest of the data is shared with the original template. This saves a lot of disk space and
speeds up VM creation, because there’s no need to duplicate the full image.
• VM Configuration Management with Pre-edited Profiles
When you manage hundreds of VMs, manually setting up each one's disk, network, memory, and CPU becomes slow and error-prone. Instead,
pre-edited profiles (ready configuration files) are used to automatically set up VMs according to standard rules, making the management of large
VM numbers faster, easier, and more consistent.
• Simplifying VM Configuration with Automatic Value Adjustment
Each VM needs to have a few unique settings, like a different UUID (unique ID), VM name, and IP address. Pre-edited profiles handle this
automatically by filling in these unique values during deployment. This way, all VMs stay consistent in setup but still have the differences needed
for them to run properly without conflict.
• Choosing the Right Physical Host for Best Performance
When starting a VM, it’s important to select the best available physical server. A smart strategy ensures that VMs are placed where there are
enough free resources (like CPU and memory), which prevents overloading any single server. This helps balance the workload across the
network and makes sure that all VMs run smoothly without performance problems.
Live VM Migration Steps and Performance Effects
Cluster Setup with Hosts and Guests
• In a virtual cluster, normally, everything runs directly on physical machines.
• If a virtual machine (VM) fails, another VM on a different physical machine can quickly replace it, as long as they have the same
operating system.
• This offers more flexibility than traditional clusters (where a physical server replaces another).
• Problem: If the physical host fails, the VM also fails.
• Solution: Use live migration to move the VM to another host before failure happens.
What is Live VM Migration?
• Live migration means moving a running VM from one physical machine (Host A) to another (Host B) without shutting it down.
• It copies the VM’s current state (memory, settings) from storage to the new host, so the service keeps running smoothly with
very little downtime.

Four Ways to Manage a Virtual Cluster:

a) Guest-Based Cluster Manager
• The manager runs inside a VM (guest system). c) Independent Managers for Host and Guest
• Multiple VMs together form a cluster. • Separate managers on both hosts and guests.
• More flexible, but more complicated to manage.
• Example: openMosix (Linux VMs) and Sun's Oasis (Solaris VMs).
b) Host-Based Cluster Manager
d) Integrated Manager for Host and Guest
• The manager runs on the physical machine (host system).
• One manager controls both physical and virtual resources.
• It controls and restarts VMs if something fails.
• Needs to know which resources are physical and which are virt
• Example: VMware High Availability (HA).
Advantages of Virtual Clusters:
• VMs can move from one machine to another easily if problems occur.
• Virtual clusters are very useful for cloud platforms, computational grids, and high-performance
computing.
• They allow resources to be quickly gathered when needed — ideal for modern cloud systems.

Challenges in Live Migration:

• Goal: Move VMs with:
• Very little downtime (service barely stops),
• Low network usage (so it doesn't overload the network),
• Fast total migration time.
• Also, while migrating, the process must not slow down or disrupt other services running on the same
host.

VM States Before and During Migration:

• Inactive: VM is created but not running yet.
• Active: VM is running and doing real work.
• Paused: VM is running but temporarily stopped, waiting to resume work.
• Suspended: VM’s state is saved to disk; it’s not running until resumed.
Six Steps of Live Migration
Step 0 and Step 1: Start Migration
• Before moving a VM, the system prepares everything.
• It selects which VM will move and chooses the destination host.
• Migration can be started manually by users or automatically based on needs like load balancing or server consolidation
(reducing the number of running servers to save energy).
Step 2: Transfer Memory
• A VM’s running state is stored in memory (RAM).
• The system copies all the memory data to the destination machine.
• But while copying, the VM is still running, so some memory data keeps changing ("dirty" memory).
• The system keeps re-copying only the changed parts in rounds until the amount left is very small.
• This way, the VM continues working almost without interruption.
Step 3: Suspend the VM and Copy the Final Data
• When almost everything is copied, the VM is paused (execution stops briefly).
• Then, the last bits of memory and other important information (like CPU state and network connections) are transferred.
• This short pause is called the “downtime”, during which the VM's services are temporarily unavailable.
• Goal: Keep this downtime very short so users don’t notice it.
Step 4 and Step 5: Commit and Activate the New Host
• Once everything is copied, the VM restarts on the new machine.
• It reloads its state and resumes working normally.
• The network connection is redirected to the new location.
• The old VM is removed from the original (source) machine.
• Migration is now complete, and users continue using the service smoothly.
Migration of Memory, Files, and Network Resources
• Building and running clusters requires lots of money for hardware, power supply, and cooling systems. To avoid waste, it's better
to share clusters instead of letting them sit idle.
• Multiple users can share the same cluster at different times, making the system more efficient and cost-effective because
unused resources are minimized.
• Older cluster systems used methods to set clear roles for each part of the cluster and physically separate the machines based
on different services like web hosting, database management, etc.
• When moving a VM to a new machine, you must properly move its memory contents, files, and network connections so that the
service remains available and uninterrupted.

Memory Migration
• Memory migration is crucial because moving a VM’s memory (hundreds of MBs to a few GBs) quickly and efficiently.
• Different apps (like web servers or databases) may need different migration methods.
• Internet Suspend-Resume technique uses memory similarity. Since memory changes little over time (temporal locality), ISR
sends only the changed parts, not everything.
• Files are broken into small pieces: Files are divided into small parts (tree structure), and only changed pieces are transferred
during migration.
• ISR causes more downtime because ISR stops the VM completely before moving it, and users face longer service interruptions.
File System Migration
• To make virtual machine (VM) migration work properly, the VM must always see the same file system no matter which
physical machine it runs on.
• One basic method is to give each VM its own virtual disk and move this disk along with VM, because disks today are very large,
copying entire disk over the network during migration is slow and inefficient.
• Better solution is to use a global file system that is accessible from all machines. Hence, there is no need to move files
when a VM migrates because files are always available over the network.
• In ISR method, a distributed file system is used only to transfer the paused state of a VM. The VM itself does not directly
use distributed file system. Instead, the VM Manager (VMM) uses its local file system and manually moves the needed
files into or out of the local system during suspend or resume operations. This makes development easier, as there’s no
need to write special code for each type of distributed file system.
• This method requires VMM to carry VM’s virtual disk content with it, which can be a burden.
• Smart copying helps reduce this burden by using the idea of spatial locality. Since users usually switch between a few
locations (like home and office), it is possible to send only the differences between those file systems when a VM is
suspended and resumed.
• If there is no locality pattern, another approach is to rebuild much of the state at the new location. This works because
user files take up only a small part of the disk, while system and app files take up most of the space.
• When we can predict the destination machine, a proactive state transfer method can be used, where files are sent in
advance, reducing the time needed during the actual migration.
Network Migration
• When a virtual machine (VM) moves from one system to another, it should keep all its network connections active. To do this, each
VM is given a virtual IP address, which stays the same no matter where the VM moves. This address is different from the actual IP
of the machine it's running on. The VM may also have a virtual MAC address, and the system keeps track of these addresses so
that communication continues smoothly.
• If the old and new systems are on the same local network, the new machine can send a special message (ARP reply) to let others
know that the IP address has moved. This helps other systems update their routing so data is sent to the right place. Although a
few data packets might get lost during the move, the connection remains mostly uninterrupted. Another method is to let the VM
keep its original MAC address, and the network will detect its new location automatically.
• Live migration allows a VM to move from one physical machine to another without stopping it. This is useful in companies for
tasks like fixing systems without downtime, adjusting system loads, or preventing failures. It makes managing computer resources
easier and supports things like combining servers and keeping applications running smoothly.
• Normally, in live migration, all the VM's memory is copied to the new machine while the VM is still running. Later, only the changed
memory pages are copied again in several steps. This keeps the downtime very low, so users may not even notice the move.
• While this method works well, copying changed memory pages again and again can slow down the network and reduce
performance. Although adjusting the data transfer rate helps, it makes the entire process longer. Also, some programs keep
changing memory constantly, making it hard to finish the copying steps quickly.
• A smarter way is to use a method called CR/TR-Motion. Instead of copying memory pages, it sends a smaller file that records what
the VM does (its execution trace). This reduces the total data and makes the migration much faster. But this only works if the new
machine can replay the actions faster than they are being recorded.
• Another method is called postcopy. Here, the VM starts running on the new machine first, and then memory pages are fetched as
needed. This makes the total migration quicker, but downtime is longer because the VM has to wait for data before it can fully
work.
• Since modern systems have many CPU cores, we can use them to compress memory data before sending it. This reduces the data
size, speeds up the process, and doesn’t need much memory to decompress. It’s a good way to make migration more efficient.
Live Migration of VM Using Xen
The following example explains how to perform live VM
migration between two Xen-enabled host machines.
Domain 0 (or Dom0) performs tasks to create, terminate,
or migrate to another host. Xen uses a send/recv model
to transfer states across VMs.

Dynamic Deployment of Virtual Clusters

Table 3.5 summarizes four virtual cluster research
projects. We briefly introduce them to identify their
design objectives and results. The Cellular Disco at
Stanford is a virtual cluster built in a shared-memory
multiprocessor system. The INRIA virtual cluster was built
to test parallel algorithm performance. The COD and
VIOLIN clusters will be studied in future examples.
VIRTUALIZATION FOR DATA-CENTER AUTOMATION
• Data centers have grown rapidly as major IT companies like Google, Amazon, Microsoft, and others invest
heavily in building and automating them.
• These companies have spent billions to ensure their data centers can dynamically allocate hardware, software,
and databases to millions of users with guaranteed quality and cost-efficiency. This has driven by the growth of
virtualization and cloud computing services.
• Virtualization improves mobility, reduces downtime, and supports more virtual clients. Later, virtualization
developments focus on high availability (HA), backup, workload balancing, and growing user support.
• The market focus shifts to HA, utility computing, consolidation, and larger client bases.
• Next, topics like server consolidation, virtual storage, OS support, and trust management in automated data
centers will be discussed.
Server Consolidation in Data Centers
• Data centers run various workloads: some are chatty (like video streaming) and some are noninteractive
(like scientific computing). These have different resource needs, so they are often given enough resources
for peak times, leading to waste.
• Many servers stay underused, wasting hardware, power, and cost. Server consolidation reduces physical
servers and improves efficiency. Virtualization-based consolidation is best, offering more flexible resource
use.
• Virtualization makes management complex but brings benefits like better hardware use, easier backup,
quicker OS deployment, and reduced overall cost (less hardware, power, and maintenance).
• Server virtualization also improves availability. If one VM crashes, others stay safe. VMs are easy to move
as they aren’t tied to physical hardware.
• Automation needs smart resource scheduling and power management. Scheduling happens at VM, server,
or data-center levels, though most systems handle only one or two.
• Dynamic CPU allocation adjusts based on usage and QoS. Some systems adapt CPU and memory
automatically. A two-level system (local VM and global server controllers) manages this.
• Multicore processors (CMP) and virtualization work well together, but CMP needs better memory use.
Virtual memory layers, inter-VM sharing, and VM-aware power budgeting improve performance and save
power.
Virtual Storage Management
• In system virtualization, it refers to storage managed by virtual machine monitors (VMMs) and guest operating
systems. Data is divided into VM images (unique to virtualization) and application data (like regular OS data).

• System virtualization emphasizes encapsulation and isolation— where each VM runs its own OS and apps
separately. But while CPUs and system software advanced to support this, storage systems lagged, becoming a
bottleneck.

• A virtualization layer added between hardware and OS complicates storage. Guest OSes act like they have real
hard disks, but don’ t directly access them. With many VMs on one machine, storage becomes harder to
manage.

• VM storage operations like volume remapping or disk checkpointing are often slow and complex. With
thousands of VMs, storage gets overwhelmed. Solutions aim to simplify storage management and save space.

• Parallax is a storage system built for virtualization. It uses Content Addressable Storage (CAS) to reduce VM
image size. Parallax shifts complex storage features from hardware to special storage VMs, which run alongside
user VMs and give each one a virtual disk.
Cloud OS for Virtualized Data Centers
• Virtualized data centers use Virtual Infrastructure (VI) managers or cloud OSes to manage servers. Four main
ones are Nimbus, Eucalyptus, OpenNebula (open-source), and vSphere 4 (proprietary).
• These tools help create and manage VMs and virtual clusters. Nimbus and Eucalyptus support virtual
networks, while OpenNebula adds dynamic provisioning and reservations.
• All three open-source tools use Xen or KVM hypervisors. vSphere 4 uses ESX/ESXi and uniquely supports
virtual storage, networking, and data protection.
Trust Management in Virtualized Data Centers:

• A VMM (Virtual Machine Monitor) sits between the OS and hardware, enabling multiple VMs on one machine. Each VM
encapsulates its OS state, which can be copied, shared, or deleted like a file, raising security concerns.
• The VMM controls hardware access and ensures secure isolation, forming the core of virtual system security. A management
VM often has special rights to control other VMs.
• If attackers gain access to the VMM or management VM, they can compromise the entire system. A specific issue is random
number reuse in protocols after VM rollback, which can break encryption or enable TCP hijacking.

VM-Based Intrusion Detection

• Intrusion detection identifies unauthorized access to a computer. IDS systems are based on OS-level features and classified
as host-based (HIDS) or network-based (NIDS). HIDS works on the monitored system but can be attacked itself, while NIDS
monitors network traffic but can’t detect fake actions.
• Virtualization-based IDS provides isolation between guest VMs. Even if one VM is compromised, others remain unaffected,
like in NIDS. VMM can audit hardware and software access, avoiding fake actions like HIDS.
• VM-based IDS can be implemented either as a separate process in each VM or as a high-privileged VM within the VMM.
Another approach is to integrate the IDS directly into the VMM itself. Garfinkel and Rosenblum proposed an IDS that runs on
the VMM as a high-privileged VM.
• A VM-based IDS includes a policy engine and module. It monitors events in VMs through OS interface libraries. PTrace helps
enforce policies on monitored hosts. Since it's hard to block all intrusions instantly, analyzing the attack afterward is crucial.
• Most systems use logs to study attack behavior, but logs must remain credible and intact. If the OS is compromised, the log
system must still function correctly. The IDS log service runs at the OS kernel level.
• Honeypots and honeynets are also used in intrusion detection. They attract attackers and present a fake system view, helping
analyze attacks and improve IDS. A honeypot mimics a vulnerable OS to observe attacker actions and exists in both physical
and virtual forms. In a virtual honeypot, the host OS and VMM must be protected from the VM.