A: A Type 1 hypervisor runs directly on physical hardware — it is the first software layer the hardware executes, and it mediates all resource access for guest operating systems above it. A Type 2 hypervisor runs on top of a host operating system, which mediates hardware access on its behalf. The architectural consequence is direct: a Type 1 hypervisor controls the scheduling model, memory allocation, and failure domain boundaries for every guest workload. A Type 2 adds a host OS as an intermediary, which introduces latency, limits isolation guarantees, and adds a failure surface. Enterprise virtualization infrastructure is built on Type 1 hypervisors because the control plane authority, performance characteristics, and isolation properties required for production workloads cannot be reliably delivered through a Type 2 architecture.

A: NUMA — Non-Uniform Memory Access — describes a physical memory architecture where CPU access latency to memory depends on which NUMA node the memory resides on. When a virtual machine’s vCPUs are scheduled across physical cores that span two NUMA nodes, memory access for that VM becomes non-uniform: half its memory accesses are local-latency and half are remote-latency. The hypervisor scheduler can be configured to enforce NUMA locality — keeping vCPUs and their associated memory on the same NUMA node — but this constraint is only applied when it is explicitly configured. Environments that ignore NUMA topology at the VM placement layer discover the performance consequence at the application layer, typically as latency anomalies that are difficult to attribute because the virtualization layer is no longer a visible concern.

A: A failure domain is the set of components that fail together when a single failure event occurs. In virtualized infrastructure, the hypervisor host is the fundamental failure domain: if the host fails, every VM running on it fails simultaneously. The cluster is a larger failure domain: if the shared storage fabric fails, all VMs across the cluster that depend on that storage are affected. HA and DRS policies define recovery behavior within and across failure domains — but they do not redefine the domains themselves. The failure domain boundaries defined at the virtualization layer are inherited by every recovery architecture built above it. Architects who do not model failure domains explicitly at the hypervisor layer typically discover their boundaries during an incident rather than during design.

A: VM isolation provides hardware-enforced memory and compute separation — one VM cannot access another’s memory space through the hypervisor abstraction under normal conditions. This isolation is sufficient for most workload separation requirements. It becomes insufficient when the threat model includes hypervisor-layer vulnerabilities (VM escape exploits), when regulatory requirements mandate physical host separation rather than logical isolation, or when workload characteristics require dedicated hardware resources that cannot be shared without performance interference. The distinction matters architecturally because teams that treat VM isolation as absolute often discover its limits at exactly the moment a security boundary is under pressure.

A: The hypervisor CPU scheduler arbitrates access to physical CPU cores across all VMs on a host. Under normal load, each VM receives its requested vCPU allocation without significant queuing delay. Under contention — when aggregate vCPU demand exceeds physical core availability — the scheduler begins making priority decisions: some VMs receive their cycles immediately, others wait. The wait time is CPU ready time, and it is the contention signal architects should be designing against. Workloads with latency-sensitive characteristics — databases, real-time processing, financial services applications — must be sized and placed with contention behavior in mind, not idle behavior. The overcommit ratios that look safe at 30% utilization produce a different scheduling environment at 80%.

A: Kubernetes does not replace the virtualization layer — in most enterprise environments, it runs on top of it. The scheduling assumptions Kubernetes makes about node resources are directly shaped by the hypervisor behavior beneath the nodes. CPU ready time from a contended hypervisor scheduler appears to Kubernetes as node-level latency — the Kubernetes scheduler has no visibility into the cause. NUMA misalignment at the hypervisor layer produces memory bandwidth constraints that Kubernetes resource requests cannot model. Failure domains defined at the hypervisor layer become the blast radius boundaries that pod scheduling and replication policies operate within, often without the Kubernetes administrator knowing where those boundaries are. Virtualization mechanics matter in cloud-native infrastructure because they are the physical layer that cloud-native abstractions assume is deterministic — when that assumption breaks, the breakage appears two layers up.