System administration

• Manage Compute users
• Manage volumes
  • Volume multi-attach
• Manage Flavors
  • Create a flavor
  • Modify a flavor
  • Delete a flavor
  • Default Flavors
• Compute service node firewall requirements
• Injecting the administrator password
• Manage the cloud
  • Show usage statistics for hosts and instances
• Logging
  • Logging module
  • Syslog
  • Rsyslog
  • Serial console
• Secure with rootwrap
  • Configure rootwrap
  • Configure the rootwrap daemon
• Configure live migrations
  • KVM-libvirt
  • XenServer
  • VMware
• Live-migrate instances
  • Manual selection of the destination host
  • Automatic selection of the destination host
  • Monitoring the migration
  • What to do when the migration times out
• Configure remote console access
  • Overview
  • noVNC-based VNC console
  • SPICE console
  • Serial
  • RDP
  • MKS
  • XVP-based VNC console
  • About nova-consoleauth
  • Frequently Asked Questions
  • References
• Configure Compute service groups
  • Database ServiceGroup driver
  • Memcache ServiceGroup driver
• Recover from a failed compute node
  • Evacuate instances
  • Manual recovery
  • Recover from a UID/GID mismatch
  • Recover cloud after disaster
• Advanced configuration
  • Attaching physical PCI devices to guests
  • CPU topologies
  • Huge pages
  • Attaching virtual GPU devices to guests
  • File-backed memory
  • Using ports with resource request
  • Attaching virtual persistent memory to guests

To effectively administer compute, you must understand how the different installed nodes interact with each other. Compute can be installed in many different ways using multiple servers, but generally multiple compute nodes control the virtual servers and a cloud controller node contains the remaining Compute services.

The Compute cloud works using a series of daemon processes named nova-* that exist persistently on the host machine. These binaries can all run on the same machine or be spread out on multiple boxes in a large deployment. The responsibilities of services and drivers are:

Services

nova-api

Receives XML requests and sends them to the rest of the system. A WSGI app routes and authenticates requests. Supports the OpenStack Compute APIs. A nova.conf configuration file is created when Compute is installed.

nova-compute

Manages virtual machines. Loads a Service object, and exposes the public methods on ComputeManager through a Remote Procedure Call (RPC).

nova-conductor

Provides database-access support for compute nodes (thereby reducing security risks).

nova-objectstore

A simple file-based storage system for images that replicates most of the S3 API. It can be replaced with OpenStack Image service and either a simple image manager or OpenStack Object Storage as the virtual machine image storage facility. It must exist on the same node as nova-compute.

nova-network

Manages floating and fixed IPs, DHCP, bridging and VLANs. Loads a Service object which exposes the public methods on one of the subclasses of NetworkManager. Different networking strategies are available by changing the network_manager configuration option to FlatManager, FlatDHCPManager, or VLANManager (defaults to VLANManager if nothing is specified).

Deprecated since version 14.0.0: nova-network was deprecated in the OpenStack Newton release.

nova-scheduler

Dispatches requests for new virtual machines to the correct node.

nova-novncproxy

Provides a VNC proxy for browsers, allowing VNC consoles to access virtual machines.

Note

Some services have drivers that change how the service implements its core functionality. For example, the nova-compute service supports drivers that let you choose which hypervisor type it can use. nova-network and nova-scheduler also have drivers.