Docker Containers vs. Virtual Machines: A Comparative Study of Architecture, Performance, Configuration, and Security Faraz Gurramkonda, Akanksha Malla, Sayma Tamboli, and Shayesta Nazneen
arXiv:2609.16148v1 [cs.SE] 14 Sep 2026
Department of Computer and Information Science University of Michigan–Dearborn, Dearborn, MI, USA {gfaraz, amalla, saymat, shayesta}@umich.edu Abstract—Modern application platforms must isolate workloads while preserving deployment speed, portability, resource efficiency, and security. Virtual machines (VMs) and Docker containers address this requirement at different abstraction layers: VMs virtualize hardware and run independent guest operating systems, whereas containers isolate processes while sharing the host kernel. This paper presents a comparative, literature-based analysis of the two approaches across architecture, configuration and lifecycle management, performance, scalability, and security. Published studies generally associate containers with shorter startup times, smaller images, higher workload density, and near-native execution for many workloads. These benefits depend on workload characteristics, storage and network drivers, resource controls, and experimental design. VMs introduce greater overhead but offer independent kernels, heterogeneous guest operating systems, and a stronger isolation boundary. The comparison therefore treats efficiency and isolation as a design trade-off rather than declaring one technology universally superior. A hybrid architecture, in which containers run inside hardened VMs, often provides a practical balance for cloud and multi-tenant systems. Index Terms—containerization, Docker, virtual machines, virtualization, hypervisors, performance evaluation, cloud computing, operating-system security
synthesis of reported performance evidence, a threat-oriented security analysis, and a practical technology-selection framework. The analysis is literature-based and does not claim a new controlled benchmark. Numerical results are treated as findings of the cited studies because virtualization performance varies with hardware, software versions, workload type, and configuration. II. A RCHITECTURAL F OUNDATIONS A. Virtual-Machine Architecture A VM stack normally contains physical hardware, a host or bare-metal hypervisor, virtual hardware, a guest operating system, guest libraries, and applications. A Type-1 hypervisor executes directly on hardware, whereas a Type-2 hypervisor runs above a host operating system. In both cases, the guest kernel owns the operating-system view inside the VM. This separation permits heterogeneous guest operating systems and provides a strong boundary between workloads, but it duplicates kernels and background services and therefore increases memory, storage, and boot overhead.
I. I NTRODUCTION B. Docker-Container Architecture Modern software systems frequently run multiple applications on shared infrastructure. Two dominant isolation mechanisms are hardware virtualization, commonly implemented through virtual machines, and operating-system-level virtualization, commonly implemented through containers. Both improve consolidation and reproducibility, but they differ in trust boundaries, resource overhead, startup behavior, portability, and operational workflow. A VM exposes virtual hardware to a guest operating system. Each VM contains an independent kernel, system services, libraries, and application processes. Docker packages an application with its user-space dependencies as an image and executes the resulting container as an isolated set of processes on a shared host kernel. Linux namespaces separate process identifiers, networks, mounts, users, and other resources, while control groups account for and limit CPU, memory, and I/O consumption [9], [10]. This paper reorganizes the original course report into a research-paper structure. It provides a layered architectural comparison, a concise account of configuration workflows, a
Docker uses operating-system-level virtualization. The Docker Engine manages images, containers, networks, volumes, and the container lifecycle. An image contains application binaries and user-space dependencies in reusable layers. At runtime, containers share the host kernel but receive isolated views of selected kernel resources. This design avoids a separate guest kernel per application and enables fast creation, high density, and portable packaging. The trade-off is that every container depends on the security and compatibility of the shared kernel. III. C ONFIGURATION AND L IFECYCLE M ANAGEMENT A. Container Workflow A container workflow describes the environment declaratively through an image definition, stores configuration separately from the image, and creates disposable runtime instances. Images can be versioned and distributed through registries, supporting consistent execution across development, test, and production environments. Listing 1 presents an abbreviated
TABLE I A RCHITECTURAL C OMPARISON Dimension
Virtual Machine
Docker Container
Virtualization layer Operating system Image composition Typical footprint Startup model OS flexibility Isolation boundary Typical strength
Hardware abstraction managed by a hypervisor Independent guest kernel and user space Guest OS, services, libraries, and applications Often hundreds of MB to several GB Guest operating-system boot Supports heterogeneous guest operating systems Separate guest kernels and virtual hardware Compatibility and strong separation
Operating-system-level isolation managed by a runtime Shared host kernel; packaged application user space Application, libraries, configuration, and filesystem layers Often tens or hundreds of MB, depending on the image Isolated process creation from an image Requires compatibility with the host-kernel family Process isolation within a shared kernel Portability, density, and rapid deployment
Virtual Machine
Containers
Applications
Containers: Apps + Libraries
Guest OS and Kernel
Docker Engine
Virtual Hardware
Namespaces and cgroups
Hypervisor Shared Host OS and Kernel Physical Hardware Physical Hardware
Fig. 1. Conceptual comparison of VM and container layers.
Docker Swarm configuration lifecycle based on the workflow discussed in the original report. Listing 1. Docker Swarm configuration lifecycle printf ’%s\n’ ’This is a config’ | docker config create my-config docker service create --name redis \ --config my-config redis:alpine
operating system, specialized virtual hardware, or a stronger workload boundary. Cloud platforms commonly combine the models by running orchestrated containers inside VM-based worker nodes. IV. P ERFORMANCE E VIDENCE A. Method The original report considered CPU computation, memory throughput, storage I/O, web-request throughput, image size, startup time, and operation speed, with tools including Sysbench, Phoronix Test Suite, ApacheBench, IOzone, Intel Linpack, and Glances. This revision uses those dimensions as a framework for synthesizing published evidence rather than presenting a new experiment. Results from different publications are not pooled because their hardware, hypervisors, operating systems, Docker versions, workloads, and resource allocations are not identical. B. Synthesis of Reported Results
Prior studies commonly observe lower overhead for containers, particularly for startup, image footprint, and memory use [1]–[3], [8]. Raj and Nath reported VM start and stop times measured in seconds, compared with millisecond-scale container operations for a prebuilt ReactJS environment [2]. Their Docker image was also substantially smaller than the Configuration objects should not contain secrets; secret- corresponding VM image. Potdar et al. evaluated CPU, memory, management facilities should be used for credentials and keys. storage, load, and execution-time behavior using standard Services and configuration objects should be removed after benchmark suites and reported favorable Docker results across experiments to prevent stale resources. several tested workloads [3]. Yadav et al. similarly reported lower request-execution times for Docker than for a KVMB. Virtual-Machine Workflow based VM in their environment [1]. Configuring a VM generally requires selecting a hypervisor, These findings should not be generalized as a fixed percentcreating virtual hardware, allocating CPU, memory, storage, age advantage. Containers may approach native performance and networking, installing a guest operating system, applying because processes use the host kernel directly, while VMs guest tools and updates, and configuring firewalls and access introduce guest-kernel and virtual-device layers. Performance controls. Snapshots provide recovery points, while templates nevertheless changes with hardware-assisted virtualization, reduce repeated installation effort. Infrastructure-as-code can paravirtualized drivers, storage back ends, networking modes, automate the process, but the deployed unit remains larger and NUMA placement, CPU pinning, memory overcommit, and more stateful than a container image. orchestration overhead. Big-data experiments also show that Containers usually integrate naturally with continuous in- application tuning and resource configuration can be as tegration and continuous deployment because an immutable important as the virtualization mechanism [5]. image can move through multiple environments. VMs remain A credible future benchmark should use identical hardware, valuable when applications require a different kernel, an older pin equal CPU and memory resources, record software versions, docker service ps redis docker config inspect my-config docker service update --config-rm my-config redis docker service rm redis docker config rm my-config
TABLE II P ERFORMANCE I NTERPRETATION BY D IMENSION Dimension
Expected Container Behavior
Startup and shut- Process creation from an existing image; typically down fast CPU
Often near native for compute-bound workloads
Memory
No duplicated guest kernel per container
Storage I/O Network
Can be fast, but layered filesystems may add overhead Bridge, NAT, and overlay choices affect latency
Density
More instances per host are usually practical
Expected VM Behavior
Important Controls
Full or partial guest-OS boot and shutdown
Warm/cold state, image cache, initialization services Small to workload-dependent virtualization overhead CPU pinning, frequency scaling, vCPU allocation Guest kernel and services consume additional Page cache, ballooning, limmemory its, overcommit Depends on virtual disk and paravirtualized driver Cache mode, filesystem, volume driver, record size MTU, offload, bridge or Virtual NIC and switch affect latency host mode, driver Lower density because each VM contains an OS Service footprint, reservation, isolation target
repeat trials, report confidence intervals, distinguish cold from warm starts, and publish scripts and raw measurements. V. S ECURITY A NALYSIS A. Container Security Namespaces and cgroups provide useful isolation and resource governance, but they do not create an independent kernel. Container security depends on the host kernel, runtime, daemon configuration, image provenance, and application privileges. Important threats include vulnerable or malicious images, an exposed Docker daemon, excessive Linux capabilities, privileged containers, unsafe bind mounts, unrestricted intercontainer traffic, weak secret handling, and unpatched kernel vulnerabilities [9], [10]. Mitigations include minimal and trusted base images, image signing and scanning, non-root execution, rootless mode where feasible, removal of unnecessary capabilities, seccomp and mandatory-access-control profiles, read-only filesystems, network segmentation, resource limits, protection of the daemon socket, and rapid patching of the host and runtime. B. Virtual-Machine Security VMs place an independent guest kernel between the application and hypervisor, generally strengthening tenant isolation. They remain exposed to hypervisor vulnerabilities, VM escape, insecure virtual-device implementations, side-channel attacks, vulnerable images, stale snapshots, weak management interfaces, and VM sprawl. Mitigations include minimizing and patching the hypervisor, isolating management networks, hardening guest images, encrypting sensitive storage, restricting administrative APIs, monitoring guest and hypervisor logs, and enforcing lifecycle policies. No virtualization technology is secure by default. The appropriate comparison is between hardened configurations under a defined threat model. NIST recommends addressing risks across images, registries, orchestrators, containers, and host operating systems rather than relying on isolation alone [9].
VI. T ECHNOLOGY-S ELECTION F RAMEWORK Selection should begin with workload and risk requirements rather than a universal preference. • Prefer containers when rapid scaling, high density, immutable delivery, microservices, and CI/CD speed dominate, and workloads can share a compatible host kernel. • Prefer VMs when workloads require different operating systems or kernels, include legacy dependencies, demand stronger tenant boundaries, or require specialized virtual hardware. • Prefer a hybrid design when teams need container portability and orchestration together with VM-level tenant, node, or regulatory boundaries. Cost comparisons should include not only instance density but also operational tooling, staff expertise, patching, monitoring, backup, licensing, incident response, and compliance. A container’s smaller footprint does not automatically make it the correct unit for every stateful or security-sensitive workload. VII. D ISCUSSION The evidence supports three broad observations. First, containerization reduces duplicated operating-system components and therefore improves startup speed and workload density in many environments. Second, VM overhead has declined with hardware-assisted virtualization and optimized drivers, making the difference workload-dependent rather than absolute. Third, isolation and performance are related: the shared kernel that gives containers their efficiency also concentrates risk at the host boundary. Several limitations constrain this comparison. The reviewed experiments use different hardware and software versions, and some measurements compare a warm, prebuilt container with a cold VM boot. Benchmark tools approximate only selected production behaviors. Long-running services may care more about tail latency, noisy-neighbor interference, failure recovery, and operational control than initial startup time. Future work should evaluate containers, VMs, and containers-in-VMs on identical modern platforms using reproducible workloads and security configurations.
TABLE III S ECURITY T RADE - OFFS AND C ONTROLS Area
Docker Containers
Virtual Machines
Primary boundary High-impact compromise Artifact risk Network risk Preferred controls
Namespaces, capabilities, cgroups, and kernel security modules Host-kernel or daemon compromise can affect multiple containers
Hypervisor, virtual hardware, and independent guest kernels Hypervisor compromise or VM escape can affect multiple guests
Vulnerable images, embedded secrets, untrusted registries Permissive bridges, published ports, overlay misconfiguration Least privilege, image scanning/signing, seccomp, MAC profiles
Best fit
Trusted or moderately trusted workloads with strong hardening
Vulnerable templates, stale snapshots, unpatched guest images Virtual-switch, management-plane, and segmentation errors Hypervisor hardening, guest patching, management isolation, inventory Untrusted tenants, distinct kernels, high-assurance separation
VIII. C ONCLUSION Docker containers and virtual machines solve related isolation problems at different layers. Containers package applications efficiently, start quickly, and support high-density, portable deployment. VMs consume more resources but provide independent guest kernels, heterogeneous operating-system support, and a stronger default isolation boundary. Published performance studies generally favor Docker for startup, image size, memory footprint, and many application workloads, but the magnitude of improvement is configuration- and workloadspecific. Security likewise depends on implementation and hardening rather than the technology label alone. For many production environments, the most practical architecture is not an exclusive choice: containers provide the application-delivery unit, while VMs define infrastructure and trust boundaries. R EFERENCES [1] R. R. Yadav, E. T. G. Sousa, and G. R. A. Callou, ”Performance comparison between virtual machines and Docker containers,” IEEE Latin America Transactions, vol. 16, no. 8, pp. 2282–2288, Aug. 2018, doi: 10.1109/TLA.2018.8528247. [2] R. Raj S and B. Nath K, ”A comparative study of using virtual machine and Docker container for deploying a ReactJS web application,” International Research Journal of Engineering and Technology, vol. 7, no. 5, pp. 1913–1917, May 2020. [3] A. M. Potdar, D. G. Narayan, S. Kengond, and M. M. Mulla, ”Performance evaluation of Docker container and virtual machine,” Procedia Computer Science, vol. 171, pp. 1419–1428, 2020, doi: 10.1016/j.procs.2020.04.152. [4] A. Yadav, L. Garg, and R. Mehra, ”Docker containers versus virtual machine-based virtualization,” in Emerging Technologies in Data Mining and Information Security, Singapore: Springer, 2019, doi: 10.1007/978981-13-1501-5 12. [5] Q. Zhang, L. Liu, C. Pu, Q. Dou, L. Wu, and W. Zhou, ”A comparative study of containers and virtual machines in big data environment,” in Proc. IEEE 11th Int. Conf. Cloud Computing (CLOUD), 2018, pp. 178–185, doi: 10.1109/CLOUD.2018.00030. [6] B. B. Rad, H. J. Bhatti, and M. Ahmadi, ”An introduction to Docker and analysis of its performance,” International Journal of Computer Science and Network Security, vol. 17, no. 3, pp. 228–235, Mar. 2017. [7] P. Prakash and R. Suresh, ”Comparative analysis on Docker and virtual machine in cloud computing,” International Journal of Pure and Applied Mathematics, vol. 117, no. 7, pp. 175–184, 2017. [8] W. Felter, A. Ferreira, R. Rajamony, and J. Rubio, ”An updated performance comparison of virtual machines and Linux containers,” in Proc. IEEE Int. Symp. Performance Analysis of Systems and Software (ISPASS), 2015, pp. 171–172, doi: 10.1109/ISPASS.2015.7095802. [9] M. Souppaya, J. Morello, and K. Scarfone, Application Container Security Guide, NIST Special Publication 800-190, National Institute of Standards and Technology, Sep. 2017, doi: 10.6028/NIST.SP.800-190. [10] Docker, Inc., ”Docker Engine security,” Docker Documentation. [Online]. Available: https://docs.docker.com/engine/security/. Accessed: Sep. 14, 2026.