Browse Prior Art Database

Mechanism for Managing Container Runtime State Disclosure Number: IPCOM000244345D
Publication Date: 2015-Dec-03
Document File: 4 page(s) / 100K

Publishing Venue

The Prior Art Database


Disclosed is a set of mechanisms that enable any applications running in containers to be checkpointed and the container’s runtime state shared across host. The mechanisms for managing the runtime state of containers include checkpointing and storing the runtime state of the applications running in a container at any time in local host; uploading container runtime state into a repository and allowing the stored state to be accessed and restsored by any host; and tracking the history of runtime state to enable state versioning.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 47% of the total text.

Page 01 of 4

Mechanism for Managing Container Runtime State

A container is an operating system (OS)-level virtualization mechanism providing multiple and simultaneous isolated user-space contexts. Unlike virtual machines, containers do not have a dedicated kernel. Isolation is implemented as functions in the host kernel.

Containers are increasingly being used to run applications with state (state in memory and disk). Currently, there is no mechanism to allow the runtime state of containers to be managed (i.e. state capture, state share, and state version control). Runtime state of a container refers to data that reside on disk and /or in memory; runtime state is necessary for the on-going and correct operation of processes in a container . Lacking these features decreases the portability, and hence, the usefulness, of using containers and is a major hindrance to the adoption of containers in the cloud .

The novel contribution is a set of mechanisms that enable :

• Checkpointing and storing the runtime state of the applications at any time running in a container on a local host

• Uploading a container runtime state in a repository and allowing any host to access and restore the stored state

• Tracking the history of runtime state to enable version control

The core novelty resides in providing the ability for any applications running in containers to be checkpointed and share the associated runtime state with other users or applications. To do this, the system combines a set of individual mechanisms : state checkpoint/restore, repository for shared state access, and state versioning for tracking state changes. The capture of the exact runtime state of containers is through the association of the memory state with the filesystem state at runtime .

Overall, no comprehensive solutions exist to provide users with the ability to manage the runtime state of applications in containers . Related work offers some solutions, but those can be cumbersome, and current systems do not provide support for memory state, do not offer runtime state management , and cannot associate memory state with the file system state of the container, nor provide mechanisms for storing and retrieving container runtime state.

The main implementation steps for the novel solution are checkpointing the running container, pushing (uploading) the runtime state to repository, pulling (downloading), and restoring the runtime state on a host.

Figure 1 illustrates the three main steps of this solution . (1) The host A (e.g., a physical machine or virtual machine) runs a container, wherein the runtime states (in-memory and on-disk) are updated by application processes. (2) At any time, the checkpoint operation can be used to capture the in-memory state along with the filesystem state and store those locally as image data. The image data is then pushed to the remote registry. Because the same container can be checkpointed multiple times during its life


Page 02 of 4

cycle, the met...