Deploy Nova Cells v2 – OpenStack Compute Scaling Guide

Guide to deploying OpenStack Nova Cells v2 for multi‑cell compute scaling, including prerequisites, cell creation, service mapping, validation steps, and recovery options.

Desired outcome

Deploy a production‑grade OpenStack Nova deployment split into multiple cells. Each cell runs its own conductor, database, and message queue, allowing the control plane to scale horizontally and isolate failures across thousands of compute nodes.

Prerequisites

A working OpenStack control plane (Keystone, Glance, Placement, Neutron) with API services reachable.
Separate MariaDB/Galera clusters or dedicated databases for each Nova cell (including cell0).
Separate RabbitMQ clusters for each cell’s messaging bus.
Network connectivity from the API tier to each cell’s database and message broker; firewall rules must allow TCP 3306 (MySQL) and 5672/5671 (AMQP).
Administrative credentials that include the cell_admin role.
All Nova services (api, scheduler, conductor, compute) running the same version across cells.

Step‑by‑step deployment

Configure cell0 databases. Edit /etc/nova/nova.conf on the API host:

[api_database]
connection = mysql+pymysql://nova:password@cell0-db-host/nova_api
[database]
connection = mysql+pymysql://nova:password@cell0-db-host/nova

Sync the APIs and cell0 database. Run as root or a user with sudo:
```
nova-manage api_db sync
nova-manage db sync
```

Create the first compute cell (cell1). Replace placeholders with your actual credentials and hostnames:

nova-manage cell_v2 create_cell \
  --name=cell1 \
  --transport-url=rabbit://nova:password@cell1-rabbit-host:5672/ \
  --database_connection=mysql+pymysql://nova:password@cell1-db-host/nova

Map computes to the new cell. After deploying nova-compute on the target hosts (with cell‑specific nova.conf pointing to cell1’s transport URL and database), run:
```
nova-manage cell_v2 discover_hosts --verbose
```
Deploy cell‑specific services. On each compute host, ensure nova-compute uses the cell1 config. On dedicated controller nodes for the cell, run nova-conductor and nova-scheduler with the same cell1 configuration. Repeat steps 3‑5 for additional cells as needed.

Expected checks

List cells and verify URLs:
```
nova-manage cell_v2 list_cells
```
Look for entries showing transport_url and database_connection with a status of enabled.
Confirm compute services belong to the correct cell:
```
openstack compute service list --host 
```
The Zone column should reflect the cell name (e.g., cell1).
Create a test instance in each cell to validate end‑to‑end flow:
```
openstack server create --image cirros --flavor m1.tiny \
  --availability-zone cell1:compute01 \
  test-cell1-instance
```
Check that the instance reaches ACTIVE state and can be accessed via its console log.
Verify Placement sees the compute nodes under the correct parent provider:
```
openstack resource provider list --parent-provider-uuid 
```
Each compute node should appear as a child of the cell’s root provider.
Monitor conductor logs for heartbeat messages:
```
grep "Cell .* is up" /var/log/nova/conductor.log
```
Regular entries indicate healthy cell communication.

Troubleshooting and recovery options

Cell mapping fails. Re‑run the mapping and discovery steps:

nova-manage cell_v2 map_cell0
nova-manage cell_v2 discover_hosts

Database corruption. Restore the affected cell’s database from the most recent backup, then re‑run nova-manage db sync for that cell.
RabbitMQ partition or loss of quorum. Ensure the cluster is healthy (rabbitmqctl cluster_status), then restart the impacted nova-conductor services:
```
systemctl restart nova-conductor
```
Removing a cell. Only after evacuating all instances (openstack server migrate --live or cold migrate) can you safely delete the cell:
```
nova-manage cell_v2 delete_cell --uuid <cell-uuid>
```
Use this command with caution; it removes the cell’s metadata permanently.

Limitations and verification tips

Cell0 must never run nova-compute; it only handles API‑level constructs and instance mappings.
During an OpenStack upgrade, apply schema migrations to each cell database independently.
Live migration of instances across cells is not supported; only cold migration (stop‑start) works.
All Nova services must run the same version; mixed versions cause RPC incompatibilities.
Verify network reachability before starting services: telnet <db-host> 3306 and telnet <rabbit-host> 5672 should succeed.

Deploying OpenStack Nova Cells v2 for Multi‑Cell Compute Scaling