Nova has various components that we will install. A representation of the communication flow among the components is shown in the following block diagram:

Nova utilizes other services such as Glance to provide images and Cinder for block volumes, which is also not shown in the block diagram. Nova supports multiple hypervisors such as KVM, Qemu, XenServer, and VMware.

The Nova Compute service is the one that takes care of communication with different hypervisors using virtualization drivers. Each and every supported Hypervisor has a driver associated with it. You can see the drivers and the code associated with these in the nova/nova/virt directory of the source code. Also, please note that the optional components such as nova-xvpnvncproxy, nova-spicehtml5proxy, or euca tools are not shown in the block diagram.

The block diagram shows the major functional components of Nova, and they can be installed on a single node or multiple nodes as they all communicate using the message bus. However, there are certain restrictions on the high availability aspect of the design, which is beyond the scope of this book.

Nova, like all OpenStack components, exposes all of its functionalities using APIs. Any custom code implementing the API, Horizon, or the command-line utilities can be used to request and modify compute resources. However, a console-based access mechanism is also given to the user; they can use this to login to the guest virtual machines that have been spun up.

The Nova API is the subsystem that is responsible for accepting the API calls from different sources; with Nova, we can also offer users access to their virtual machine consoles, a functionality which is not exposed in public clouds, such as that of AWS.

The console is not a mandatory component, especially if we are just trying to match the features of the public cloud. The console functionality is dependant on different services such as the VNC proxy and console authentication. Depending on the hypervisor, we may need more than these services to enable the console feature.

So, once Nova API gets a request, what does it do next? It leaves the request on the Advanced Message Queueing Protocol (AMQP) message queue for the Nova Scheduler to pick up. The Nova scheduler is responsible for finding a physical server with the available resources to fulfill the request. It finds the server, and again leaves the request in the message queue.

Nova Compute is the service that runs on the hypervisor and interacts with it. It picks up the message from the queue and creates the compute resource. The ephemeral storage for this compute is processed by the Nova Volume. If we need permanent storage, then we have already set up Cinder in the previous chapters; this can expose the block storage to the compute resource that we create.

Of course, the record for all actions is kept in the database, but in the case of Nova, the Nova Conductor is responsible for writing and reading from the database in order to keep the data coherent and avoid locking issues.

We will install all the components with the exception of Nova Compute on the Controller node. Nova compute will be installed on the compute node.