Glossary of TermsΒΆ


Channels are the key component of the ZeroVM I/O subsystem. On the host system side, channels are backed by the file system using regular files, pipes, character devices, or TCP sockets. On the guest side, each channel is a device file, which can either be used as a character or block device.

Channels are the only way for ZeroVM to communicate with the “outside world”, i.e., the host file system, other ZeroVM nodes, etc. Before a ZeroVM instance starts, channels must be declared in the manifest.

Daemon mode
ZeroVM can be started in daemon mode to reduce startup of instances/nodes in a multi-node job. Although ZeroVM startup time is ~5ms, user programs, for example, running on zpython, will incur an additional startup penalty. Daemon mode allows a multi-node computation to “pre-warm” an instance and fork additional copies for each unit of computation, thereby paying the additional startup time penalty only once.

A text file which must be provided to ZeroVM in order to run a NaCL application. Manifest files must include the following mandatory fields:

  • Version: Manifest format version.
  • Program: Full path to a NaCL application to be validated and run.
  • Timeout: Timeout, in seconds. ZeroVM will stop the user program and exit after the specified time has elapsed. Valid values are 1..2147483647.
  • Memory: Memory space in bytes available for the user program.
  • Channel: Mapping for I/O between a ZeroVM instance and the host system. Multiple channels be specified in a manifest.

Manifests can also contain the following optional fields:

  • Nameserver: Address of a nameserver which resolves network channel definitions.
  • Node: Node ID number of a given ZeroVM instance in a cluster of VMs. Manditory if NameServer is specified.
  • Job: Path to a Unix socket. Used for receiving commands/manifests and to send reports in daemon mode.
Native Client
NVRAM (configuration file)

INI-style configuration file used by ZeroVM and the ZRT. Includes the following:

  • [fstab] section: Channel definitions for tar images to be mounted as directory/file hierarchies in the in-memory file system.
  • [env] section: Environment variable definitions.
  • [mapping] section: Channel definitions for stdin, stdout, stderr, and other devices not included in [fstab].
  • [debug] section: Optional. Debug verbosity level configuration.
  • [time] section: Optional. Defines the starting time for the ZeroVM clock. With this you can define the number of seconds since Jan 1, 1970. (See Unix time.)
System Map
The system map is the JSON configuration file that is passed to the ZeroCloud middleware when executing a job within ZeroCloud.
ZeroVM and the ZRT. Provides a secure sandbox for running untrusted code.
User code run inside the ZeroVM NaCL-based sandbox. Untrusted code is validated before it is run.
Custom-configured deployment of ZeroCloud, hosted by Rackspace. Zebra is an alpha-testing service and playground for ZeroCloud.

Middleware for OpenStack Swift which provides the capability to run ZeroVM applications on object storage nodes. Can be used to initiate map/reduce-style jobs on collections of Swift objects.


ZeroVM Application
An archive file (typically created by zpm) containing a zapp.yml configuration file and user application code.
ZeroVM Package Manager

Command-line utility which helps to create, bundle, deploy (to ZeroCloud), and execute (on ZeroCloud) ZeroVM user applications.


ZeroVM Runtime
Provides a POSIX-like environment and in-memory file system for use by untrusted user programs.
ZeroVM Shell

Utility program which makes ZeroVM easy to use by providing rich command-line options for running and debugging ZeroVM instances. Also includes manifest/NVRAM configuration file generation functionality (so you don’t have to write all of your configuration files by hand).


ZeroVM ports of CPython interpreters. There are ongoing efforts to port both Python 2.7.3 and Python 3.2.2 to run inside ZeroVM.
Deprecated synonym for ZeroCloud.