COMP 3150Operating Systems

01 Overview

CourseCOMP 3150 / CMIS 3150 — Operating Systems
UnitUnit 13 — Virtualization and Cloud Operating Systems
WeightPart of the 5% participation grade (each discussion is worth approximately 0.4% of the final grade)
OpensMonday of Week 13
Initial post dueThursday of Week 13, 23:59
Peer replies dueSunday of Week 13, 23:59
FormatOne initial post (600–800 words, including a comparison table) and at least two substantive peer replies (150–250 words each)
CLOs assessedCLO6, CLO7, CLO8

02 Learning outcomes addressed

By participating in this discussion you will

  • Explain the architecture of virtual machines and hypervisors, and the role of hardware-assisted virtualization (U13.1, U13.2).
  • Describe the mechanisms of container isolation — namespaces, cgroups, capabilities, LSMs (U13.3).
  • Explain the role of container images, registries, and orchestration (U13.4, U13.5).
  • Describe the architecture of a cloud operating system and the challenges it addresses (U13.6).
  • Evaluate emerging isolation technologies — microVMs, unikernels, WebAssembly — against established ones (U13.7).
  • Take a position on a forward-looking question and defend it with evidence (U13.7).

This discussion assesses CLO6 (apply operating-system tools), CLO7 (evaluate OS technologies), and CLO8 (design OS-related components).

03 Discussion prompt

Background

Five isolation technologies are in common use or active development today. Each makes different trade-offs:

  • Virtual machines — full guest OS in a hypervisor. Strongest isolation; slow startup; heavy memory footprint.
  • Containers — shared kernel with namespaces, cgroups, and LSMs. Fast startup; dense; weaker isolation (a kernel vulnerability is an escape vector).
  • MicroVMs (Firecracker, Kata Containers) — a stripped-down guest kernel booted in milliseconds. VM-grade isolation at near-container speed and density.
  • Unikernels — an application linked with the OS libraries it needs, running on a hypervisor with no user/kernel separation. Minimal attack surface; very fast startup; requires re-architecting the application.
  • WebAssembly (Wasm) runtimes (Wasmtime, WasmEdge) — a sandboxed, portable bytecode format with a capabilities-based interface (WASI). Extremely fast startup; strong sandboxing; a new execution model that many languages cannot yet target well.

Your task

  1. Choose one class of workload from the list below:
    • Serverless functions. Thousands of short-lived, event-driven invocations per second, from many tenants, with a cold-start target of under 100 ms.
    • Multi-tenant SaaS platform. Untrusted customer code running in the same cluster, tenants mutually distrusting, long-running workloads.
    • Edge computing. Workloads running on devices with constrained resources and intermittent connectivity, where the deployment artefact must be small and updates must be fast.
    • Traditional enterprise application. A long-running, stateful service (for example, a database or a legacy application) that requires kernel-level features and predictable performance.
  2. Take a position. For your chosen workload, argue which of the five technologies (or which combination) will be the standard in five to ten years. State your position clearly in the first paragraph.
  3. Support your position with evidence. Your argument should address all four dimensions:
    • Isolation — how strong is the boundary between tenants?
    • Density — how many instances can run on a host?
    • Startup time — how quickly can an instance be created?
    • Performance — what is the overhead in the data path?
    Cite at least two sources (a paper, a vendor's engineering blog, or a documented production deployment).
  4. Present the comparison. Include a table with one row per technology and columns for isolation, density, startup time, and performance, plus a column for your rating of its suitability for your chosen workload (for example, Excellent / Good / Poor).
  5. Address the counter-argument. State which technology your strongest opponent would choose, and explain why your position is stronger for the workload you chose. Be honest about the conditions under which you would change your mind.
  6. Reflect on the trajectory. Isolation technologies have evolved over time: from physical servers to VMs, from VMs to containers, and now from containers to microVMs and WebAssembly. What does this trajectory suggest about the kinds of isolation that future workloads will need? What problems will the next generation of isolation technology have to solve?

Your post should be 600–800 words, with the comparison table included. A well-argued position that disagrees with the consensus is worth more than a correct-but-unengaged summary, as long as the argument is supported by evidence and acknowledges the trade-offs.

04 Notes on the technologies

4.1 Virtual machines

A VM runs a full guest operating system inside a hypervisor. Because the guest has its own kernel, the isolation boundary is the hypervisor — a relatively small, well-audited piece of software — rather than the Linux kernel itself. VMs are the standard for enterprise workloads and multi-tenant hosting. Their main drawbacks are the memory footprint of the guest OS (hundreds of megabytes even for a small workload) and the startup time (seconds to tens of seconds).

4.2 Containers

A container is a group of processes on the host with its own namespaces and cgroup limits. The container shares the host kernel, so its isolation is only as strong as the kernel's namespace and LSM implementations. Containers start in milliseconds and have negligible memory overhead, making them ideal for dense, elastic workloads. The main risk is a kernel vulnerability that allows a container escape.

4.3 MicroVMs

A microVM (for example, AWS's Firecracker) boots a minimal guest kernel in tens of milliseconds and uses only a few megabytes of memory. It provides the isolation of a VM with the density and startup time of a container. Firecracker powers AWS Lambda and Fargate; Kata Containers brings the same model to Kubernetes. The trade-off is that the guest kernel must be stripped down (no PCI enumeration, no BIOS, a minimal device model), which limits what the guest can do; the workload must be adapted to the reduced device set.

4.4 Unikernels

A unikernel links an application with only the OS libraries it uses, producing a single-address-space image that runs directly on a hypervisor. There is no user/kernel separation, no system-call boundary, and no general-purpose OS. The image is small (often under a megabyte) and boots in milliseconds. The trade-off is that the application must be structured to work without a general-purpose OS — no fork, no signals, no dynamic linking — which requires re-architecting existing software.

4.5 WebAssembly

WebAssembly (Wasm) is a portable bytecode format that runs in a sandboxed VM. A Wasm module has no direct access to the host's file system, network, or memory; any such access must be explicitly granted through a capabilities-based interface (WASI). Modules start in microseconds and are typically a few hundred kilobytes. The trade-offs are language support (C, C++, Rust, and Go compile well; others are catching up) and the lack of system-level features (threads, signals, direct I/O) that traditional applications expect.

4.6 The trajectory

Each transition — from physical to virtual, from virtual to container, from container to microVM — has traded some isolation for some efficiency, or recovered isolation without giving up the efficiency gains of the previous step. The pattern suggests that future workloads will require both strong isolation and high density, because multi-tenancy is becoming the default and the tenants do not trust each other. The next generation of isolation technology will have to solve this without requiring applications to be rewritten — a constraint that unikernels, for all their elegance, have not satisfied.

05 Grading rubric

The discussion is marked out of 100 points. The criteria and their weights are given below.

Discussion 13 grading rubric — weights
CriterionWeight
Post quality (position, evidence, comparison, reflection)40%
Peer response quality30%
Engagement and timeliness20%
Netiquette and clarity10%

5.1 Post quality (40 points)

LevelDescriptor
Exemplary (90–100%) A clear position stated in the first paragraph. The argument is supported by evidence from at least two sources and addresses all four dimensions (isolation, density, startup time, performance). The comparison table is complete and accurate. The counter-argument is addressed fairly and honestly. The reflection on the trajectory of isolation technologies is insightful and connects to the workloads the next generation will need to serve.
Proficient (80–89%) A clear position. The argument is supported by evidence and addresses most of the four dimensions. The comparison table is present. The counter-argument is mentioned but not fully addressed. The reflection is present but brief.
Developing (70–79%) A position is stated, but the argument is largely descriptive and does not engage with the four dimensions. The comparison table is incomplete. The counter-argument and the reflection are missing or superficial.
Beginning (60–69%) No clear position, or the position is not defended. The post summarises the technologies without evaluating them.
Not demonstrated (<60%) The post is missing, off-topic, or a restatement of the prompt.

5.2 Peer response quality (30 points)

The descriptors are the same as for Discussion 1. An exemplary reply might challenge the classmate's position with a concrete counter-example (a real deployment where the other technology won), introduce a technology or trade-off the classmate did not consider, or extend the reflection with an argument about what the trajectory suggests.

5.3 Engagement and timeliness (20 points)

The descriptors are the same as for Discussion 1.

5.4 Netiquette and clarity (10 points)

The descriptors are the same as for Discussion 1.

06 Resources

  • Silberschatz, A., Galvin, P. B., & Gagne, G. Operating System Concepts, 10th ed., Chapter 18 (Virtual Machines).
  • Tanenbaum, A. S., & Bos, H. Modern Operating Systems, 4th ed., Chapter 7 (Virtualization and the Cloud).
  • Smith, J. E., & Nair, R. Virtual Machines: Versatile Platforms for Systems and Processes. Morgan Kaufmann, 2005.
  • Rosenblum, M., & Garfinkel, T. Virtual Machine Monitors: Current Technology and Future Trends. IEEE Computer, 2005.
  • Agache, A., et al. Firecracker: Lightweight Virtualization for Serverless Applications. USENIX NSDI, 2020.
  • Manco, F., et al. My VM is Lighter (and Safer) than your Container. ACM SOSP, 2017.
  • Bernstein, D. Containers and Cloud: From LXC to Docker to Kubernetes. IEEE Cloud Computing, 2014.
  • Burns, B., et al. Borg, Omega, and Kubernetes. ACM Queue, 2016.
  • The WebAssembly specification and the WASI documentation.
  • Open Container Initiative (OCI) specifications.
  • Linux man-pages: man 7 namespaces, man 7 cgroups, man 1 unshare, man 1 docker, man 1 qemu-system-x86_64.
👤