A developer starts a Linux virtual machine on a laptop. A familiar boot sequence appears, the guest discovers several CPUs and hardware devices, and eventually a login prompt becomes available.

Inside the virtual machine, Linux behaves as though it owns a computer. It installs a kernel, manages processes, configures network interfaces, and writes a file system to a disk.

The laptop has not created another physical processor, memory module, or storage device. A virtualization layer has created a machine-shaped execution environment and retained control over how that environment uses the laptop.

This produces two distinct operating-system roles:

The component that preserves this separation is the hypervisor, also called a virtual machine monitor, or VMM.

A virtual machine is an isolated software-defined computer. A hypervisor creates and controls that computer while mediating its access to physical hardware.

The guest can run an ordinary operating-system kernel because the virtual environment presents the processor, memory, interrupts, and devices that a kernel expects. The central challenge is letting the guest behave like a kernel without allowing it to take control of the host.

A host is the physical machine and the trusted software that manages its hardware. Depending on the virtualization design, the host may include a conventional host operating system or a smaller platform built primarily to run virtual machines.

A guest is an operating system running inside a virtual machine. Linux, Windows, or another supported operating system can be a guest.

The virtual machine is the complete guest-visible computer: its virtual CPUs, guest memory, firmware, storage devices, network adapters, timers, interrupt controllers, and other configured hardware.

The hypervisor maintains those virtual resources and controls their connection to the physical system.

The virtual machine should not be confused with its virtual disk image. The image may contain the guest's bootloader, operating system, applications, and persistent data, but the running VM also has CPU state, memory contents, device state, and a resource configuration.

Nor is the hypervisor the guest operating system. The guest kernel still performs ordinary operating-system work inside its VM: it schedules guest processes, handles their system calls, manages their virtual address spaces, and operates virtual devices through drivers.

The hypervisor works at the machine boundary below that guest kernel. It decides when a vCPU can execute, which host memory and devices support the VM, and what must happen when the guest attempts an operation requiring host control.

Starting a VM resembles powering on a physical computer because the guest needs a believable machine startup sequence.

A simplified flow is:

This is the same sequence a physical machine follows. Nothing in it is aware that the hardware is virtual.

The firmware may implement a virtualized form of UEFI or another boot interface. The guest bootloader and kernel interact with that firmware and the configured devices much as they would on a physical machine.

When the guest probes a storage controller, it discovers a virtual controller. When it configures a network adapter, it configures a virtual adapter. The hypervisor and supporting software connect these devices to host-side implementations.

This design allows an existing operating system to run without being rewritten as an ordinary host application. From the guest kernel's perspective, it booted on a computer whose particular hardware happens to be virtual.

The platform presented to the guest can differ from the host's exact hardware. A host with a modern network adapter might present a simpler emulated adapter for compatibility or a virtualization-aware adapter for performance. The guest must have drivers for the devices it sees, not necessarily for the physical devices installed in the host.

An operating-system kernel normally expects authority over the machine. It configures memory protection, controls interrupts, communicates with devices, and executes processor operations unavailable to applications.

Two guest kernels cannot both receive unrestricted control of the same physical host. If Guest A could disable physical interrupts or overwrite the host's hardware configuration directly, it could stop Guest B and the hypervisor itself.

The hypervisor must therefore control several boundaries:

For each VM, the hypervisor also maintains machine state such as virtual CPU registers and virtual device configuration.

The guest can change its virtual state without gaining arbitrary authority over the host. For example, it can mask interrupts for one virtual CPU, but that must not prevent the host from receiving physical interrupts needed by every other workload.

This is the hypervisor's fundamental rule:

Let the guest control its virtual machine while reserving control of the physical machine for the host.

Applications normally run with less processor privilege than an operating-system kernel. The kernel uses privileged instructions and protected state to control memory, devices, interrupts, and execution.

A guest contains both of those levels:

There are two kernels in this stack, each authoritative over a different machine. The guest kernel is fully in charge of a machine that does not physically exist.

Simply running the entire guest at application privilege would create problems. The guest kernel expects to execute kernel-only operations and to receive the faults and interrupts needed to manage its processes.

Running the guest kernel with unrestricted physical-machine privilege would be worse. A bug or malicious guest could modify host state, access another VM, or disable the protection mechanism.

The processor and hypervisor therefore cooperate to provide a controlled guest execution mode. The guest kernel can retain its internal privilege boundary relative to guest applications, while the hypervisor retains authority over the complete physical machine.

Modern x86 processors provide hardware virtualization extensions commonly known as Intel VT-x and AMD-V. Other processor architectures provide comparable facilities. These features add controls and saved state for running guests without pretending that a guest kernel is an ordinary unprivileged application.

The exact hardware terminology differs by architecture. The important conceptual hierarchy is that a guest kernel has authority over its guest applications, while the hypervisor retains authority over the guest kernel's use of the machine.

The first relationship is enforced within the virtual machine. The second ensures that even guest-kernel operations remain confined to that VM.

Most guest instructions do not need special handling. Arithmetic, ordinary control flow, and many memory operations can execute directly on a physical CPU while the processor is in guest mode.

The hypervisor configures which events require its attention. An event can include an operation affecting controlled machine state, an access to an emulated device, an external interrupt, or an explicit request from virtualization-aware guest software.

When such an event occurs, the processor stops guest execution and transfers control to the hypervisor. This transition is commonly called a VM exit.

The hypervisor examines the exit reason, performs the required action or updates virtual state, and resumes the guest through a VM entry.

Suppose a guest writes to a register belonging to an emulated device. The access can cause a VM exit. The hypervisor or a device model interprets the write, changes the virtual device's state, and possibly initiates host I/O. The guest later receives a virtual interrupt indicating completion.

This general pattern is often described as trap and emulate: guest execution traps into the controlling layer, the hypervisor reproduces the operation's guest-visible effect, and the guest resumes.

Hardware assistance means the hypervisor does not need to inspect every instruction. It establishes the execution controls, and the processor runs the guest directly until a configured event requires mediation.

VM exits are not free. The processor must save guest state, enter the hypervisor, execute handling code, and restore guest execution. Hypervisors and virtualization-aware software try to avoid unnecessary exits on common paths.

A system call made by a guest application is not automatically a request to the host hypervisor.

Suppose a program inside a Linux guest calls getpid(). The transition is:

The guest enters guest kernel mode on a system call, handles getpid(), and returns to guest user mode.

The guest kernel owns the guest's process IDs and can answer the request. There is no reason to ask the host for a physical-machine operation.

Even a file read first enters the guest kernel, not the hypervisor:

Only when the request reaches a virtual resource requiring host-side work does it cross the VM boundary.

Some guest-kernel actions can themselves cause VM exits because they touch processor state controlled by the hypervisor. The key distinction is that a system call crosses from a guest application to the guest kernel, while a VM exit crosses from guest execution to the hypervisor.

Conflating the two leads to an incorrect model in which the hypervisor behaves like the operating-system kernel for guest applications. The guest already has a kernel; the hypervisor controls the virtual machine on which that kernel runs.

Each vCPU has guest-visible processor state: general registers, control state, interrupt state, and other architecture-specific information.

When a vCPU is allowed to run, the hypervisor arranges for a physical CPU to execute using that guest state. When the vCPU stops running, its updated state remains associated with the VM so it can continue later. A physical CPU can therefore run one vCPU, save its state, and later run a vCPU belonging to another VM.

The host can represent vCPUs as schedulable host entities. With KVM on Linux, for example, each vCPU is commonly driven by a host thread, so the Linux scheduler participates in choosing when and where it runs.

If a VM has four vCPUs, the guest sees four logical processors. They can execute in parallel when physical capacity is available. They can also wait when the host is busy or when more runnable vCPUs exist than physical CPU capacity.

Configuring more virtual CPUs than the host can run simultaneously is one form of overcommitment. It can improve utilization when VMs are often idle, but it can also create delay when they become busy together.

A Linux guest may account for time during which a runnable virtual CPU waited for the host as steal time. Tools such as top can display it as %st:

In this illustrative output, the guest reports that 20% of the measured CPU time was unavailable because the host was running something else. The exact accounting depends on the platform, but sustained steal time is evidence that guest-visible CPU demand and host scheduling capacity are not the same thing.

An operating system expects hardware devices, so a VM platform must give the guest a device interface. There are three broad implementation approaches.

Emulated devices

An emulated device reproduces the interface of a hardware device that a guest operating system already knows how to use.

This is valuable for compatibility. An unmodified guest with an existing driver can boot and communicate with the emulated controller even when the host has completely different physical hardware.

Compatibility can add overhead. The guest driver performs operations designed for a physical device, those operations must be intercepted, and a software device model reproduces their effects.

Paravirtualized devices

A paravirtualized device exposes an interface designed specifically for virtual environments. The guest uses a virtualization-aware driver that communicates more directly with the host-side implementation.

The virtio family is a common example in KVM-based environments. Virtio storage and network drivers exchange requests through shared queues and notification mechanisms rather than imitating every detail of a legacy physical device.

This reduces unnecessary emulation work, but the guest needs the matching driver.

Device passthrough

With device passthrough, the host assigns a physical device, or a hardware-supported portion of one, more directly to a VM. The guest can use a native device driver and avoid much of the software device path.

Passthrough can improve performance and reduce host CPU overhead. It also reduces flexibility: the device may no longer be freely shared, and moving or snapshotting the VM becomes harder when its state depends on particular hardware.

These approaches can coexist in one VM. A guest might use emulated firmware devices during boot, virtio for its main disk and network traffic, and passthrough for a specialized accelerator.

Consider a network packet sent by an application inside a guest using a paravirtualized network adapter:

The guest application uses an ordinary socket. The guest kernel processes the socket operation and network data using its own stack. The guest driver then submits work through the virtual device interface.

On the host side, software connects the virtual adapter to a software switch, bridge, packet filter, or other networking path before traffic reaches a physical adapter.

Storage follows the same broad layering. A guest file operation may become a virtual block request, which the host backs with a file, logical volume, physical device, or remote storage system.

Each layer can queue, buffer, transform, or delay work. This is why guest-visible device latency can include time spent in the guest, the virtual device path, host software, and physical hardware.

The hypervisor does not necessarily implement every part in one privileged component. Device models, I/O helpers, and management services can run in separate host processes. “The hypervisor handles I/O” is therefore a useful conceptual shortcut, not always a literal description of one executable doing all the work.

Textbooks commonly classify hypervisors by where they sit in the software stack.

Type 1: native or bare-metal

A Type 1 hypervisor runs directly on the hardware as the platform responsible for hosting virtual machines.

Virtual machines run on a Type 1 hypervisor with its host services, which runs directly on the physical hardware.

This model is common in servers and data centers. VMware ESXi, Xen-based platforms, and Microsoft Hyper-V are commonly placed in this category.

“Bare-metal” does not mean there is no supporting software. A production platform still needs device drivers, management services, storage and networking components, logging, and an administrative interface. The label means that the platform's primary system role is to host and control VMs rather than to run the hypervisor as an ordinary desktop application.

Type 2: hosted

A Type 2 hypervisor runs on top of a conventional host operating system.

Virtual machines run on a hosted virtualization application, which runs on a host operating system, which runs on the physical hardware.

The host operating system supplies device drivers, process scheduling, files, networking, and other services. Desktop products such as Oracle VirtualBox and VMware Workstation are commonly described this way.

Hosted virtualization is convenient for development and testing because it fits into an existing desktop environment. Its implementation relies heavily on the host operating system and therefore includes that system in the VM platform's performance and trust boundary.

The classification is only a starting point

Real implementations do not always fit neatly into two boxes.

KVM turns the Linux kernel into a hypervisor by adding facilities for guest execution. Virtual machine processes and device models still run in user space, and Linux provides scheduling, memory management, drivers, and I/O. KVM is commonly treated as Type 1 because virtualization control resides in the host kernel, even though the full stack includes a general-purpose operating system.

Hyper-V similarly includes a privileged management environment alongside the hypervisor. Xen uses a privileged control domain for many management and device functions.

The type label tells you roughly where virtualization control lives. It does not, by itself, determine performance, security, or the exact I/O path.

Linux provides a useful concrete example because its virtualization responsibilities are visible across kernel and user space.

KVM, the Kernel-based Virtual Machine, is a Linux kernel facility that uses hardware virtualization support to run guest vCPUs. It exposes an interface through /dev/kvm so a user-space virtual machine monitor can create a VM, configure its virtual CPUs and memory, and enter guest execution.

QEMU can provide the user-space machine model. It creates the VM process, allocates guest memory, loads firmware, models devices, and connects virtual I/O to host resources.

With KVM acceleration, the simplified division is:

The work is split across three privilege levels. Device emulation stays in an ordinary user process, which is why a device-model bug does not automatically compromise the kernel.

QEMU can also emulate a processor entirely in software. That allows it to run a guest for a different architecture, but it is a different execution path from using KVM to run a same-architecture guest with hardware assistance.

libvirt is an optional management layer commonly used with QEMU/KVM. It provides APIs and tools for defining, starting, stopping, and inspecting VMs. It is not the component that executes guest instructions.

Keeping these names separate prevents a common source of confusion:

They are often deployed together, but they have different responsibilities.

lscpu can report whether the processor exposes hardware virtualization extensions:

Typical x86 results include:

or:

This reports a processor capability visible to Linux. It does not prove that KVM is loaded or that any VM is running.

To inspect KVM kernel modules:

An Intel host may show kvm_intel and kvm; an AMD host may show kvm_amd and kvm.

The KVM API is normally exposed through:

The device's permissions determine which users or services may create VMs. Merely seeing /dev/kvm does not grant the current user access.

On a host managed by libvirt, this command lists defined virtual machines:

An empty list means libvirt has no VMs in the current connection. It does not rule out VMs managed directly by QEMU or another tool.

These checks answer different questions:

A VM platform can control a virtual machine independently of the guest's ordinary application lifecycle.

A forced power-off or destroy operation stops the VM from the outside. Unless the guest had already made its data consistent, this resembles removing power from a physical machine.

A graceful shutdown asks the guest operating system to stop applications, flush required state, unmount file systems, and power down through its normal path.

A pause stops vCPU execution while retaining the VM's in-memory state. Host-side I/O and time behavior need careful coordination so the guest can continue consistently.

A suspend or saved-state operation stores enough runtime state to resume later. A snapshot records selected VM state, commonly disk state and sometimes memory or device state, so the platform can return to it.

These operations are not interchangeable. Capturing a disk while applications are writing can preserve a crash-consistent point rather than an application-consistent one. A database may need guest coordination before the captured state represents a clean checkpoint.

Virtual machines can also be migrated between compatible hosts. The platform must recreate the virtual hardware contract and transfer the required state while managing any changes in physical placement.

The virtual boundary makes these operations possible, but their correctness depends on which state is captured and what the guest was doing at that moment.

A virtual machine isolates guest software only if the layers enforcing that boundary behave correctly.

The trusted computing base can include the hypervisor, host kernel, device models, firmware, management services, and hardware. A Type 2 design also depends on the conventional host operating system beneath the virtualization application.

Virtual devices are an important boundary. A guest supplies device requests and data to host-side code. That code must validate lengths, addresses, descriptors, and state transitions rather than trusting the guest kernel.

Administrative access matters as well. A management service that can attach disks, read VM memory, or modify virtual networking has authority that code inside the guest does not. Compromising that service can bypass isolation without exploiting the virtual CPU boundary.

Running as the administrative user inside a guest does not normally grant administrative access to the host. Guest root controls the guest operating system and its virtual resources. The hypervisor is responsible for preventing that authority from escaping the VM.

The boundary is strong enough for many hostile multi-tenant environments, but it is not magical. Safe deployment still requires patched virtualization software, narrow management permissions, secure device configurations, and appropriate resource controls.

A virtual machine is a complete guest-visible computer containing vCPUs, memory, firmware, and devices. Its guest operating system manages applications exactly because it sees a machine interface rather than an ordinary host process interface.

The hypervisor controls the boundary below the guest kernel. Hardware virtualization lets most guest instructions execute directly while transferring control to the hypervisor for selected events through VM exits. A guest system call and a VM exit cross different boundaries.

Hypervisors schedule vCPUs and connect virtual devices to host resources. Emulated devices favor compatibility, paravirtualized devices reduce emulation overhead, and passthrough gives a VM more direct device access at the cost of flexibility.

Type 1 and Type 2 describe broad hypervisor deployment models, not guaranteed performance or security levels. In Linux virtualization, KVM provides kernel execution support, QEMU commonly provides the machine and device model, and libvirt can provide management.

The central responsibility is:

The guest controls its virtual machine; the hypervisor retains control of the physical machine.