Understanding OpenStack Nova’s Integration with Hypervisors (KVM)

OpenStack is the de‑facto standard cloud operating system for public clouds, widely adopted by vendors such as SoftLayer, Helion, FusionSphere, SUSE, Red Hat, RackSpace, Mirantis, Nebula, CloudScaling, MetaCloud, PistonCloud, and Canonical. This article discusses how OpenStack connects to underlying hypervisors and the technical principles involved.

OpenStack and the Nova Module

Nova is the compute management component of OpenStack, responsible for allocating virtual machines on demand. It operates as a service composed of several sub‑components (Nova‑API, Nova‑Scheduler, Nova‑Compute, etc.) that communicate via message queues.

All Nova components exchange information through queues; Nova‑Compute directly interacts with the hypervisor, which is the focus of this discussion.

Hypervisors Supported by OpenStack

OpenStack itself does not provide virtualization but integrates with many hypervisors, including KVM, Xen, LXC (Docker), UML, VMware vSphere, PowerVM, and Hyper‑V. The diagram below illustrates the range of supported hypervisors.

Nova‑Compute and KVM Relationship

KVM is the default and most contributed hypervisor in the OpenStack community. A typical deployment uses one control node (running Nova‑API, Nova‑Conductor, Nova‑Scheduler) and multiple compute nodes (running KVM and Nova‑Compute). When a VM creation request arrives, the Scheduler selects an appropriate compute node based on algorithms that consider CPU, memory, and other metrics.

Nova‑Scheduler notifies the chosen compute node’s Nova‑Compute, which uses a driver specific to the hypervisor. The driver, together with Libvirt, translates the request into KVM‑compatible commands, creating and managing the virtual machine.

Libvirt Architecture Overview

Libvirt is an open‑source virtualization API library that sits between OpenStack and the underlying hypervisor (e.g., KVM, Xen). It abstracts hypervisor specifics and provides a uniform API for operations such as start, stop, suspend, and live migration. Libvirt’s client component sends commands to the Libvirtd daemon, which either handles the request directly or forwards it to the hypervisor via sockets.

In summary, creating a VM in an OpenStack‑KVM environment involves the control node’s Nova‑Scheduler selecting a compute node, Nova‑Compute invoking the appropriate driver, Libvirt translating the request, and KVM executing the virtualization tasks.

For further details, readers are encouraged to follow the author’s public account and request the comprehensive guide “Server Virtualization Technology Detailed Analysis,” which covers the architecture, principles, and comparisons of five major virtualization solutions.