Container States

A container does not actually enforce the resource consumption boundaries that you set for an application. Rather, once the minimum CPU reservation and memory cap are provided and the container is activated, the Solaris kernel begins enforcing these boundaries. Before using containers, you should know more about container states. A container can be in one of the following three states: defined, active, and inactive.

Figure 3–1 Container States

A container can move between these states throughout its lifetime.

Defined Container

The container definition is created during the initial stage but the container itself is still not fully formed. Each container definition must have a unique name and can be saved indefinitely in the database.

As seen in Figure 3–1, the defined container moves into the active state after the container is associated with a host. An inactive container can move back into the defined state after it has been deactivated and is no longer associated with a host.

Active Container

The first step in making a container active is to associate its definition with a host. The second step is to set the resource boundaries, namely, to assign the minimum CPU reservation and the memory cap for the container. The container must be associated with a host that can support these resource boundaries. An active container can also be referred to as being deployed, in the sense that the container definition has been pushed out and resides on a host.

When creating an application-based container with the New Container wizard, a match expression can be provided which identifies the processes associated with the application. All processes corresponding to the match expression are then automatically moved under this container. Upon container activation, an entry in the /etc/project database is created on the host that the container is associated with. Correspondingly, the matching processes are then moved under the project name for the container. Once the processes are moved, all resource utilization data is collected and saved for the container.

Inactive Container

When a container is deactivated, the resource boundaries are no longer enforced. A deactivated container enters into an inactive state and is deleted from the host's /etc/project file. While inactive, the container still exists in the software's database, pending future activation. Once the inactive container is reactivated, the container's resource boundaries are again enforced.

All data collected about the container's use of resources while it was active is preserved in the database. You can still request utilization reports for an inactive container for up to 30 days after the container was deactivated.