Virtualization and Cloud Service Models

Prerequisites

Read Networking Foundations for Cloud Applications, or understand that an application endpoint has an address, routes, and authorization rules. You should know the roles of a processor, memory, an operating system, and an application program. No hypervisor or container experience is required.

Learning outcomes

After this lesson, you will be able to:

• explain how a hypervisor presents processors, memory, and devices to a virtual machine;
• distinguish a virtual machine from an operating-system container through kernel ownership and observable artifacts;
• compare Infrastructure as a Service, Platform as a Service, and Software as a Service without assuming that every product fits one category perfectly;
• calculate processor demand and failure headroom with explicit units;
• inspect a local execution environment for virtualization and control-group evidence; and
• explain why isolation, portability, multiple zones, and managed operation each require separate tests.

Opening concrete narrative: a machine that is not a machine

CampusCart's developer asks a cloud management application programming interface (API) for a four-virtual-processor Linux instance with 16 gibibytes of memory. The provider returns an identifier, an address, and a “running” status. The developer connects through Secure Shell (SSH) and sees processors, memory, a disk, and a network interface. The developer never sees a technician install a physical server.

Another CampusCart developer packages the API in a container image and runs two containers on that instance. Each container shows its own file tree and process identifiers. Both containers report the same Linux kernel release because both use the instance's kernel. A virtual machine can instead run a separate guest kernel because a hypervisor presents a virtual hardware interface.

CivicPermit uses two availability zones because the permit intake application must continue after one-zone loss. An architecture diagram shows one virtual machine in each zone. The PostgreSQL database, however, has only one zonal primary and no tested standby. Compute isolation and geographic placement cannot repair an application dependency that remains in the failed zone.

The investigation needs evidence at three different divisions: physical host versus virtual machine, host kernel versus container process, and provider operation versus customer operation.

Observable evidence

Inside a Linux virtual machine, lscpu can report a hypervisor vendor or a virtualization flag when the platform exposes one. systemd-detect-virt checks several known indicators. /sys/class/dmi/id/ can contain firmware identity strings. Each artifact is produced by the guest kernel or user-space program from interfaces the hypervisor chooses to expose. A missing vendor string does not prove bare metal.

The Linux path /proc/self/status exposes the current process identifiers and other kernel-maintained values. Namespace links under /proc/self/ns/ identify the process's namespace memberships. /proc/self/cgroup exposes control-group membership. The Linux kernel produces these virtual files when a process reads them. Two processes with different process-identifier namespace links have different views of process identifiers, but the difference alone does not establish strong security isolation.

A cloud instance description is a control-plane artifact. The provider API produces fields for instance type, image, zone, disks, and network interfaces. A guest operating-system log establishes what the guest observed. Provider host placement and maintenance details can remain intentionally hidden. The reported virtual central processing units (vCPUs) are guest execution interfaces, not direct proof of dedicated physical cores.

Container runtime commands produce another view. docker inspect reports configuration and runtime metadata known to the Docker daemon. A container image manifest identifies ordered filesystem content by cryptographic digest. The Open Container Initiative (OCI) Image Specification defines interoperable manifests, indexes, layers, and configuration. An image digest establishes selected content identity; the digest does not establish that the content is safe, authorized, or currently running.

Mechanism: virtual machines

A physical processor implements an instruction set and privilege rules. An operating-system kernel expects to control privileged operations such as page tables, interrupts, and devices. A hypervisor mediates that control so multiple guest operating systems can use one physical host.

The hypervisor schedules vCPUs onto physical processor execution time. The hypervisor and processor translation hardware map guest memory addresses through additional mappings to physical memory. Virtual device mechanisms translate guest disk and network actions into host or dedicated device actions. When a guest attempts a protected operation, processor hardware can transfer control to the hypervisor, which validates or emulates the action before the guest continues.

Practitioners call the resulting execution environment a virtual machine (VM). A VM has a virtual hardware contract on which a guest kernel runs. Popek and Goldberg's 1974 paper gave a formal framework for virtual-machine monitors, including equivalence, control, and efficiency properties under their modeled architecture. Modern processors and hypervisors add hardware assistance and implementation techniques beyond that historical machine model, but the control distinction remains useful.

Kernel-based Virtual Machine (KVM) provides a concrete current example. The Linux KVM API uses /dev/kvm and input/output control operations to create a VM, virtual processors, and virtual devices. User-space software supplies memory and device emulation while kernel and processor facilities execute guest work. The KVM application binary interface has been stable since Linux 2.6.22, but capabilities must be queried rather than guessed from a kernel version.

Virtualization permits consolidation and different guest kernels. Virtualization does not make memory, processor time, or network capacity infinite. Host scheduling contention can delay a guest. A physical host failure can stop several VMs. Provider placement controls determine whether replicas share a failure domain.

Mechanism: containers

A Linux container normally consists of ordinary processes that share the host's Linux kernel. Namespaces give a selected process group distinct views of kernel objects such as process identifiers, mounts, host names, user identifiers, or network interfaces. A control group, written cgroup in Linux documentation, organizes processes hierarchically and controls or accounts for resources such as processor time and memory.

The container runtime prepares a filesystem, namespace memberships, credentials, capability limits, cgroup placement, and an initial process. The kernel still schedules the resulting threads. Container processes make system calls to the host kernel; they do not boot an independent Linux kernel inside the ordinary container.

Docker is one toolset that builds images and asks a runtime to start containers. Docker is not a synonym for a container, and a container is not a miniature VM. On macOS and Windows, Docker Desktop commonly uses a Linux VM because Linux containers require a Linux kernel. The visible stack can therefore be physical laptop, desktop hypervisor, Linux VM, container runtime, and container process.

Container isolation depends on correct namespace, cgroup, capability, system-call, filesystem, device, and runtime configuration. Docker documentation states that containers have no resource constraints by default unless limits are configured. A process view can be isolated while processor consumption remains effectively unlimited within host scheduling.

Technical terms in context: service models divide control

The National Institute of Standards and Technology (NIST) describes three cloud service models. The categories name which computing capability the provider exposes and which parts the customer controls.

Infrastructure as a Service (IaaS) gives the customer processing, storage, networks, and other fundamental capacity on which the customer can run arbitrary software. The provider operates the physical infrastructure and virtualization mechanism. The customer normally controls the guest operating system, deployed applications, and much network configuration. Amazon Elastic Compute Cloud (Amazon EC2) from Amazon Web Services (AWS), Google Compute Engine, and Azure Virtual Machines are current examples, subject to each product's exact terms.

Platform as a Service (PaaS) gives the customer a provider-supported application deployment environment. The customer deploys applications with supported languages, libraries, or tools while the provider operates the underlying network, servers, operating systems, and storage mechanisms. Google App Engine's original preview made this division visible, although current platform products offer many additional options.

Software as a Service (SaaS) gives the customer use of the provider's running application, usually through a browser or API. The provider operates the application and underlying stack. The customer still manages authorized users, data use, configuration, and integration choices within the product's interface.

The following responsibility map is deliberately simplified:

| Operational object | On premises | IaaS | PaaS | SaaS | |---|---|---|---|---| | buildings, hardware, host network | customer | provider | provider | provider | | hypervisor or host kernel | customer | provider | provider | provider | | guest operating system | customer | customer | provider | provider | | language runtime and scaling mechanism | customer | customer | mostly provider | provider | | application code | customer | customer | customer | provider | | tenant configuration, identities, and lawful data use | customer | customer | customer | shared through product controls |

“Managed PostgreSQL” sits on a spectrum near PaaS: the provider patches database software and manages selected backup or failover mechanisms, while the customer designs schemas, queries, roles, retention, connectivity, and restore validation. NIST's categories are useful responsibility questions, not labels that settle every product detail. Serverless functions and managed container platforms can also combine properties.

Working model: processor demand and zone failure

Define processor demand per request as vCPU-seconds consumed by the API divided by completed requests during the same controlled load test. Assume the tested CampusCart request mix uses 0.012 vCPU-seconds per completed request. At 80 completed requests per second, expected processor demand is:

80 requests/second × 0.012 vCPU-seconds/request = 0.96 vCPU

At 400 completed requests per second, expected demand is:

400 × 0.012 = 4.8 vCPU

Assume each four-vCPU VM has a target ceiling of 60% sustained processor use to preserve latency headroom. Each VM then contributes 4 vCPU × 0.60 = 2.4 vCPU of planned capacity.

Two VMs, one per zone, provide 2 × 2.4 = 4.8 vCPU, exactly the planned peak under ordinary operation. Loss of either zone leaves only 2.4 vCPU, corresponding to 2.4 ÷ 0.012 = 200 requests per second. Two-zone placement therefore fails the 400-request-per-second zone-loss requirement.

Four VMs, two per zone, provide 9.6 vCPU normally. Loss of one zone leaves 4.8 vCPU, corresponding to the tested 400 requests per second at the 60% ceiling. The arithmetic supports a compute-capacity claim under the assumptions.

The working model assumes linear scaling, equal request mixtures, even load distribution, independent zone placement, and no database or network limit. Processor demand can rise under cache misses, garbage collection, encryption, or retries. A vCPU is a scheduled execution abstraction, not necessarily one dedicated physical core. The calculation predicts neither cost nor response-time percentiles.

Empirical test: inspect the execution boundary

On Linux, run the following read-only commands and preserve the output:

uname -a
lscpu 2>/dev/null | sed -n '1,30p'
systemd-detect-virt 2>/dev/null || true
cat /proc/self/cgroup
ls -l /proc/self/ns/
grep -E '^(Name|Pid|NSpid|Cpus_allowed_list|Mems_allowed_list):' /proc/self/status

The controlled object is one shell process. The commands observe the kernel release, reported processors, virtualization hints, cgroup membership, namespace identities, and allowed processors or memory nodes. A cgroup v2 line commonly begins 0::; cgroup v1 or hybrid arrangements show different controller fields. The installed kernel and distribution documentation control interpretation.

If Docker is already installed and an approved local image is present, compare host and container evidence without pulling new content:

docker image ls --digests
docker run --rm --network none APPROVED_LOCAL_IMAGE sh -c \
  'uname -a; cat /proc/self/cgroup; ls -l /proc/self/ns/'

Keep the host, image digest, runtime version, and command constant. Vary only host execution versus container execution. Linux containers should report the same kernel release as their Linux host, while namespace identifiers or cgroup paths can differ. Docker Desktop can insert a Linux VM, so the relevant “host” for kernel sharing is the hidden Linux VM rather than the macOS or Windows kernel.

A differing kernel release between an ordinary Linux host and its purported direct Linux container would reject the simple shared-kernel explanation and suggest a VM boundary, a remote runtime, or a mistaken comparison. Equal kernel strings do not prove isolation or common physical hardware.

Worked investigation: CivicPermit's untested database boundary

Initial question

Will CivicPermit continue to commit synthetic permit submissions after the loss of either configured availability zone?

Operating conditions

Staging has two four-vCPU API VMs, one in each zone. A managed PostgreSQL primary resides in zone A with automated backups but no configured cross-zone standby. A test client submits one synthetic permit per second. Each request carries a unique identifier and no personally identifiable information (PII). Operators use the provider's approved fault-injection procedure to make the zone-A API and database endpoints unavailable after two steady minutes.

Evidence collected

The deployment export confirms API placements and the single-zone database setting. Before intervention, 120 client requests return 201 and produce 120 unique database rows. After intervention, the traffic distributor selects the zone-B API. The next 90 client requests return 503. Zone-B API logs show database connection timeouts. No new database rows appear. Audit-log delivery continues to a regional destination.

Interpretation

The zone-B VM and API process remain available, but every submission depends on the unavailable zone-A database. The traffic switch proves compute-path failover only. Automated backup configuration provides recoverable copies under its own policy; a backup does not act as a live database endpoint.

Proposed intervention or prediction

Configure the managed PostgreSQL product's supported multi-zone standby, validate synchronous or provider-documented replication behavior, and add bounded connection retries with idempotent request identifiers. Predict that a repeated test will show a finite database failover interval, followed by one committed row per accepted identifier and no duplicates.

Observed result

In the repeated staging exercise, 71 requests return 503 during a 71-second failover interval. The next 229 return 201 through the zone-B API. PostgreSQL contains 349 unique rows: 120 before failure plus 229 after failover. No duplicate identifier appears.

Bounded conclusion

The tested multi-zone database configuration and idempotent write path restored staging commits after 71 seconds under the selected fault. The original single-zone database was the dependency that defeated the earlier two-zone claim.

Remaining uncertainty

A region-wide event, simultaneous host failures, replication lag under peak load, exhausted retry queues, backup corruption, identity failure, and provider control-plane impairment remain untested. CivicPermit's required recovery time and recovery point must be compared with the measured result by the responsible agency.

Normal case, failure cases, and qualifications

In the normal IaaS case, the provider places a VM, the hypervisor schedules vCPUs and maps memory, the guest kernel starts, and the customer's API process listens on an authorized interface. Instance metrics, guest logs, and request evidence agree about useful work. A container can package that API while the VM supplies its Linux kernel.

A noisy-neighbor edge case occurs when several guests or containers contend for shared processor, cache, storage, or network capacity. Provider isolation prevents one tenant from directly controlling another tenant's guest, but scheduling contention can still increase timing variance. Dedicated-host options change some sharing conditions, not every downstream dependency.

Memory pressure produces a different failure. A container without a suitable limit can consume host memory until the Linux out-of-memory mechanism kills a process. A hard limit can instead cause the container workload to be killed when it exceeds the configured ceiling. Processor overcommit can degrade time gradually, while unsafe memory allocation can cause abrupt termination.

Live migration and provider maintenance are implementation-specific qualifications. A provider can move or restart selected VMs according to product policy. Local ephemeral disks can have a different lifecycle from persistent block volumes. Read the current machine-family and maintenance documentation for the exact region and instance type.

Common errors

• “A vCPU is a dedicated core.” A vCPU is the processor execution interface presented to a guest. Dedication, simultaneous multithreading, scheduling, and overcommit depend on the product and host arrangement.
• “A container includes its own kernel.” An ordinary Linux container shares the host Linux kernel. A VM or sandboxed runtime can add another kernel boundary.
• “An image digest proves security.” A digest identifies content bytes. Provenance, signature policy, vulnerability review, runtime configuration, and authorization require separate evidence.
• “PaaS removes operations.” Provider staff and software perform more operations, while customers still operate code, data, identity, configuration, testing, and incident response within the exposed interface.
• “Two zones provide zone-failure capacity.” Surviving instances and every required dependency must carry the failure load. The processor calculation and database exercise show two separate ways the claim can fail.
• “Backups provide immediate availability.” A backup supports restoration. A live standby and a tested failover path address a different recovery interval.

Knowledge check

Question: A CampusCart API container and its Linux VM host report the same uname -r kernel release. Which mechanism explains the match, and which claim remains unproved?

Answer: An ordinary Linux container uses the host Linux kernel, so the shared kernel release is expected. The match does not prove secure isolation, correct cgroup limits, identical filesystem content, or common physical-host placement.

Exercises

Check

Create a responsibility table for CampusCart on IaaS, a managed application platform, and a purchased bookstore SaaS product. Include hardware, guest patching, runtime patching, application code, database schema, user access, backups, and restore tests. Submit one evidence artifact for every customer-owned row.

Practice

Run the read-only Linux inspection commands on a VM, Linux host, or approved lab environment. Preserve raw output. Annotate which program or kernel interface produced each line, which boundary the line exposes, and one claim the line cannot establish.

Challenge

Recalculate CampusCart's zone-failure capacity when a request consumes 0.016 vCPU-seconds, each VM has eight vCPUs, the planned ceiling is 55%, and peak demand is 600 requests per second. Choose an integer VM count per zone that survives one-zone loss. Submit equations with units, normal and failure utilization, assumptions, and one empirical load test that could reject linear scaling.

Authoritative sources and further reading

Required reading

• NIST Special Publication 800-145, *The NIST Definition of Cloud Computing* provides the authoritative IaaS, PaaS, and SaaS capability definitions used here.
• Popek and Goldberg, “Formal Requirements for Virtualizable Third Generation Architectures” is the primary formal paper on classic virtual-machine monitor properties and their modeled architectural conditions.

Implementation documentation

• Linux kernel: KVM API describes the stable file-descriptor and input/output-control interface used to create and operate KVM guests. Query KVM capabilities rather than relying on a version-number guess.
• Linux kernel: Control Group v2 is the rolling authoritative description of cgroup v2 hierarchy, controllers, delegation, and observable files. Match the page to the installed kernel when behavior matters.
• Open Container Initiative Image Specification defines current interoperable image manifests, indexes, filesystem layers, and configuration. The rolling site showed a November 2025 publication state when checked July 20, 2026.
• Docker: Resource constraints documents current processor and memory controls and warns that containers have no constraints by default.
• Google Cloud: Compute Engine overview identifies Compute Engine as an IaaS offering with VMs using KVM; the page was last updated July 17, 2026 when checked.
• AWS: Nested virtualization on EC2 provides a current concrete diagram of physical infrastructure and Nitro hypervisor, a guest instance, and nested guests. Supported instance types and restrictions are version-sensitive.

Advanced reference

• International Business Machines (IBM): Overview of the z/VM Control Program shows a current, explicit mapping of virtual processors, memory, and devices in a long-running VM lineage. The linked page is for z/VM 7.4.0; use the documentation matching an installed release.

Provider VM features, container runtime defaults, Linux interfaces, cgroup mode, instance maintenance behavior, and managed-platform responsibility divisions change over time. Record product, version, region, date, and configuration with every operational claim.

Next-chapter transition

The first four chapters established the cloud application map, the historical mechanisms that produced it, the network path between programs, and the compute abstractions beneath those programs. The next part can now examine provider identities, permissions, storage, databases, and the core mechanisms that turn raw infrastructure into a production cloud application.