LPIC-3 Virtualization and Containerization key terms

Software layer that creates and runs virtual machines by partitioning physical CPU, memory, and I/O among isolated guests. Type 1 runs directly on hardware; type 2 runs atop a host OS.

Linux kernel module that turns the host into a type 1 hypervisor by exposing hardware virtualization extensions (Intel VT-x, AMD-V) to userspace tools such as QEMU.

Userspace emulator and virtual machine monitor that provides virtual hardware for guests. With KVM acceleration it runs near-native; without it, it emulates CPU instructions in software.

Daemon and API that manages hypervisors such as KVM/QEMU, Xen, and LXC through a common interface, storing VM configuration as XML and exposing local and remote management.

Command-line client for the libvirt API. It starts, stops, inspects, migrates, and edits virtual machines defined in libvirt, using either the local daemon or a remote URI.

Utility for creating, converting, resizing, and inspecting disk image files. It supports formats such as raw and qcow2 and can take snapshots or check image consistency.

QEMU copy-on-write disk image format that grows on demand and supports snapshots, compression, and backing files, allowing multiple images to share a read-only base.

Paravirtualized device interface standard where the guest uses optimized drivers and the host handles I/O, giving near-native disk and network performance instead of emulating real hardware.

Moving a running virtual machine between hosts with minimal downtime by copying memory state while the guest continues executing, then briefly pausing to transfer the final changes.

Assigning a physical PCI device, such as a network card or GPU, exclusively to a guest so it drives the hardware directly, usually enabled by IOMMU/VT-d and vfio.

A cooperative memory-management technique where a driver inside the guest releases unused pages back to the hypervisor through an inflated balloon, letting the host reclaim RAM under pressure.

Allocating more virtual CPUs to guests than physical cores exist, relying on the hypervisor scheduler to time-share. It raises density but can cause latency when guests are busy.

Kernel feature that isolates what a process can see, covering mount points, process IDs, networking, hostnames, users, and IPC. Containers are built by combining several namespaces per process.

Kernel mechanism that limits, accounts for, and isolates resource use (CPU, memory, I/O, PIDs) of process groups. Container runtimes use it to enforce per-container resource boundaries.

Open Container Initiative, which publishes standards for container images, runtimes, and distribution. Compliance lets images built by one tool run under another runtime or registry.

Lightweight OCI-compliant runtime that creates a container from an unpacked filesystem bundle: it sets up namespaces and cgroups, then executes the configured process and exits.

Read-only, content-addressed bundle of filesystem layers plus configuration metadata (command, environment, ports) from which a container runtime starts one or more container processes.

One immutable filesystem-diff tarball in a container image. Layers stack in order; identical layers are shared between images and cached, which speeds builds and reduces registry storage.

Union filesystem that stacks a read-only lower layer and a writable upper layer into one view. Container runtimes use it so many containers share an image without copying it.

Network service that stores and distributes container images by repository and tag, exposing an API for push and pull; examples include Docker Hub, Harbor, and Quay.

Cryptographic hash (usually SHA-256) of an image manifest that uniquely identifies its content. Pulling by digest rather than tag guarantees the exact same image.

Text file of instructions describing how to build a container image layer by layer: base image, file copies, package installs, and runtime command, executed by a builder such as Buildah or BuildKit.

Daemonless container engine that runs OCI containers and pods under a user's own credentials. Its command line is largely compatible with Docker, and it supports rootless operation.

Container started by an unprivileged user without a root daemon, relying on user namespaces to map that user to root inside the container, reducing host attack surface.

Fine-grained privileges split out of root, such as CAP_NET_ADMIN or CAP_SYS_TIME. Container runtimes drop most capabilities by default and grant only what a process needs.

Open-source container orchestration platform that schedules workloads across a cluster of nodes, reconciles declared state, and provides service discovery, scaling, and self-healing.

Smallest schedulable Kubernetes unit: one or more containers that share a network namespace, IP address, and volumes, and are always placed together on the same node.

Kubernetes controller that manages stateless Pods through ReplicaSets, supporting rolling updates, rollbacks, and scaling by comparing desired and observed state.

Kubernetes abstraction giving a stable virtual IP and DNS name to a set of Pods selected by labels, load-balancing traffic even as Pods are recreated or rescheduled.

Node agent that receives Pod specifications from the API server, starts and monitors containers through a CRI runtime, and reports node and Pod status back to the control plane.

Distributed key-value store using Raft consensus that holds all Kubernetes cluster state. Its availability and consistency are critical, so it is usually backed up and run on dedicated hosts.

Command-line client for the Kubernetes API. It creates, inspects, edits, and deletes resources, and can port-forward, exec into Pods, and apply manifests declaratively.

Virtual cluster partition inside one physical cluster that scopes names, quotas, and role-based access, letting teams share a cluster without colliding resource names.

Kubernetes object holding non-confidential configuration as key-value pairs or files, injected into Pods as environment variables or mounted volumes so images stay environment-agnostic.

A user's request for storage in Kubernetes that binds to a suitable PersistentVolume or dynamically provisioned volume, then mounts into Pods independently of their lifecycle.

Container Network Interface, a specification and plugin set that configures Pod networking (interfaces, IP addresses, routes) when containers are created or removed.

Container Runtime Interface, the gRPC API through which kubelet talks to container runtimes such as containerd or CRI-O, decoupling Kubernetes from any specific runtime.

Package manager for Kubernetes that templates YAML manifests into charts, then installs, upgrades, and rolls back releases while tracking revision history.