Host Daemon Sharing Container Layers via DAX
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
The existing method of running application containers inside Virtual Machines (VMs) leads to data duplication and inefficient resource usage due to the duplication of identical layers across multiple VMs, resulting in redundant disk and memory content.
Innovation Solution
Implementing a system that uses a host-side container generation daemon to manage and share identical container layers across VMs through Direct Access (DAX) devices, eliminating the need for duplicate storage and caching by mapping layers directly from a shared host storage, and utilizing Overlay FS or similar file systems that operate in XIP mode to merge layers without creating additional memory caching.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Ease of operation
If each VM independently downloads and stores container layers from the registry, then each VM can run containers autonomously, but data is duplicated across multiple VMs resulting in inefficient resource usage
Solution Approach 1:
The patent merges the container layer storage across multiple VMs by implementing a shared storage mechanism where identical layers are stored only once in a common location (e.g., shared filesystem, network storage, or storage pool). The VMs access these shared layers through references or mount points, eliminating redundant copies while maintaining autonomous container operation capability.
Solution Approach 2:
The patent creates a universal layer storage system that serves multiple VMs simultaneously. A single layer repository or storage pool provides services to all VMs, allowing them to share common base images and libraries. This multi-functional storage infrastructure replaces individual VM-specific storage, reducing overall data quantity while maintaining operational independence.
2Speed
If each VM stores complete copies of container layers in local storage, then fast access is achieved, but disk space is wasted due to redundant storage of identical layers
Solution Approach 1:
The patent combines the storage infrastructure into a shared system where multiple VMs access common layer repositories. This eliminates the need for each VM to maintain separate complete copies, significantly reducing total disk space consumption while maintaining fast access through optimized shared storage paths and caching mechanisms.
Solution Approach 2:
Instead of copying entire layer images to each VM's local storage, the patent uses reference-based access where VMs hold minimal metadata or pointers to the actual layer data stored centrally. This allows fast access through efficient reference resolution while avoiding redundant data duplication across VMs.
3Adaptability or versatility
If Docker daemons in each VM pull layers independently from the registry, then each VM maintains container independence, but identical layers are downloaded multiple times increasing network bandwidth consumption
Solution Approach 1:
The patent merges the layer distribution function across VMs by implementing a coordinated pull mechanism where Docker daemons communicate or coordinate their layer requests. When one VM downloads a layer, other VMs can access it from the shared storage instead of re-downloading from the external registry, reducing network bandwidth consumption while maintaining container independence through shared access protocols.
Solution Approach 2:
The patent introduces a intermediary layer distribution mechanism between the external registry and individual VMs. This intermediary (such as a gateway daemon or shared storage interface) receives layer requests, checks for existing copies in shared storage, and distributes layers efficiently to multiple VMs simultaneously, reducing redundant network traffic while preserving container autonomy.
Data Source
AI summary
System for launching application containers inside VMs without data duplication, includes first and second VMs on a host; a storage to which the host has access; a container generation module running on the host and configured to interface to VM-side container generation daemons in the VMs; the container generation daemons transmits to the container generation module a request to pull container layers; a host-side container generation daemon processes the request to pull the container layers from the container generation daemons running inside the VMs; and a DAX device residing on each of the VMs. The host container generation daemon sends the request for any missing container layers to a registry, and writes them onto the storage, maps the layers to the VMs as the DAX devices, maps all needed container layers to the first VM and maps any identical container layers to the second VM, without accessing the registry.