Compute

nova-api accepts and responds to end user compute API calls. It supports OpenStack Compute API, Amazon's EC2 API and a special Admin API (for privileged users to perform administrative actions). It also initiates most of the orchestration activities (such as running an instance) as well as enforces some policy.

nova-api-metadata accepts metadata requests from instances (more details). The nova-api-metadata service is generally only used when running in multi-host mode with nova-network installations.

The nova-compute process is primarily a worker daemon that creates and terminates virtual machine instances via hypervisor's APIs (XenAPI for XenServer/XCP, libvirt for KVM or QEMU, VMwareAPI for VMware, etc.). The process by which it does so is fairly complex but the basics are simple: accept actions from the queue and then perform a series of system commands (like launching a KVM instance) to carry them out while updating state in the database.

The nova-schedule process is conceptually the simplest piece of code in OpenStack Nova: take a virtual machine instance request from the queue and determines where it should run (specifically, which compute server host it should run on).

The nova-conductor module, introduced in the Grizzly release, works as a “mediator” between nova-compute and the database. It is aimed at eliminating all the direct accesses to the cloud database made by nova-compute. The nova-conductor module scales horizontally but it shouldn’t be deployed on the same node(s) where nova-compute runs. You can read more about the new service here.

The nova-network worker daemon is very similar to nova-compute. It accepts networking tasks from the queue and then performs tasks to manipulate the network (such as setting up bridging interfaces or changing iptables rules). This functionality is being migrated to OpenStack Networking, a separate OpenStack service.

nova-dhcpbridge (script) This script tracks IP address leases and records them in the database using dnsmasq's dhcp-script facility. This functionality is also migrated to OpenStack Networking; a different script is provided when using OpenStack Networking (code-named Quantum).

The nova-consoleauth daemon authorizes user’s tokens that console proxies provide (see nova-novncproxy and nova-xvpnvcproxy). This service must be running in order for console proxies to work. Many proxies of either type can be run against a single nova-consoleauth service in a cluster configuration. Read more details.

The nova-novncproxy (daemon) provides a proxy for accessing running instances through a VNC connection. It supports browser-based novnc clients.

The deprecated nova-console daemon is no longer used with Grizzly, and the nova-xvpnvncproxy is used instead.

The nova-xvpnvncproxy daemon is a proxy for accessing running instances through a VNC connection. It supports a Java client specifically designed for OpenStack.

The nova-cert daemon manages x509 certificates.

The nova-objectstore daemon provides an S3 interface for registering images onto the image management service (see glance) It is mainly used for installations that need to support euca2ools. The euca2ools tools talk to nova-objectore in “S3 language” and nova-objectstore translates S3 requests into glance requests

The euca2ools client is not an OpenStack module but it can be supported by OpenStack. It’s a set of command line interpreter commands for managing cloud resources. Provided that nova-api is configured to support EC2 interface, euca2ools can be used to issue cloud management commands. For more information on euca2ools, see http://www.eucalyptus.com/eucalyptus-cloud/documentation/2.0.

The nova client enables you to submit either tenant administrator’s commands or cloud user’s commands.

The nova-manage client submits cloud administrator commands.

The queue provides a central hub for passing messages between daemons. This is usually implemented with RabbitMQ today, but could be any AMPQ message queue (such as Apache Qpid), or Zero MQ.

The SQL database stores most of the build-time and run-time state for a cloud infrastructure. This includes the instance types that are available for use, instances in use, networks available and projects. Theoretically, OpenStack Nova can support any database supported by SQL-Alchemy but the only databases currently being widely used are sqlite3 (only appropriate for test and development work), MySQL and PostgreSQL.