Ceph and OpenStack integration

How Ceph RBD backs OpenStack Glance, Cinder and Nova

An OpenStack cloud that needs shared block storage for images, volumes, guest disks and backups can use Ceph block devices (RBD) as the supported backend for all of these services. The integration works by giving each OpenStack service its own CephX key and its own RBD pool, with the service talking to the cluster through librbd. Glance stores images, Cinder manages volumes, Nova places guest disks, and Cinder Backup writes volume backups. Because Nova can attach Ceph-backed disks, virtual machines can boot from Ceph without local hypervisor storage, which makes live migration and host replacement simpler to plan. The work sits in two places at once: the Ceph cluster, where pools and keys are created, and the OpenStack deployment, where each service's configuration file points at those pools and keys. The Ceph block devices and OpenStack documentation sets out the configuration keys for each service and is the reference to follow for the exact settings in your release.

Plan the service boundaries before anyone runs a playbook. Decide which pools each service writes to, whether Glance and Cinder share a cluster or use separate ones, and which CephX user has write access to which pool. A single shared key across all four services is easier to set up but gives Nova and Cinder Backup more access than they need. Confirm with your Ceph administrator how keys are created and rotated in your cluster, and confirm with your OpenStack deployment team which configuration method (Kolla-Ansible, OpenStack-Ansible or a manual setup) will write the service settings. Each of those choices affects the later work on image format, caching and locking, so record them in the design before build starts.

What you need before connecting OpenStack to Ceph

Connecting OpenStack to Ceph touches the storage cluster, the OpenStack control plane and every compute and backup node that will open RBD images. Work through these items before any pool or key is created, because most integration delays come from a gap in one of them.

A supported Ceph release

Start from a release that is actively maintained. The Ceph releases page lists Squid (19.2.x) and Tentacle (20.2.x) as the maintained lines, with periodic backports and security fixes. Confirm the exact point release you will run, and confirm the client library version on each OpenStack node matches what your Ceph release supports. Ask your storage team which release they will standardize on before the OpenStack side is planned.

A maintained OpenStack release

Pick an OpenStack release still in the maintained phase, such as 2026.1 Gazpacho or 2025.2 Flamingo. Stable branches are maintained for roughly 18 months, and only SLURP releases may later enter an unmaintained phase, so an older release will limit your upgrade options. Confirm which release your deployment tool currently targets and whether your upgrade path follows SLURP releases.

Network reachability to Ceph

Compute, controller and backup nodes must reach the Ceph monitors on the monitor ports and the OSDs on their data ports. Ceph's messenger v2 uses port 3300 by default, so check that firewall rules, VLANs and routing allow it from every OpenStack node, not only from the ones you test first. Confirm whether the public network is routable from each node and whether you plan to enable encryption in transit between them.

Ceph client packages on each node

Every node that opens RBD images needs the Ceph client packages, including the librbd and librados libraries that Nova, Cinder and Glance use through their drivers. Version skew between these libraries and the cluster is a common source of failures that look like permission errors. Record the installed client version on each node and align it with your cluster release before you configure the drivers.

A sized and benchmarked cluster

Size and benchmark the Ceph cluster before connecting OpenStack to it. Ceph's hardware recommendations advise sizing memory for peak use, benchmarking before buying because no two clusters are alike, and separating WAL and DB onto shared SSDs for HDD-based OSDs. Shared OpenStack workloads such as boot disks and backups will expose weaknesses that a lab test does not, so know your cluster's throughput and latency limits first.

Confirmed OpenStack deployment tool

Confirm which tool manages your OpenStack nodes before you edit any driver configuration. Kolla-Ansible deploys OpenStack in Docker containers, while OpenStack-Ansible deploys in LXC containers or on bare metal, and each places Ceph configuration files and keyrings in different locations. Ask your platform team which tool owns the Glance, Cinder, Nova and backup service configuration so changes are made once, in the right place.

Configuration sequence for Glance, Cinder, Nova and Cinder Backup

This sequence takes an empty Ceph cluster to a state where Glance, Cinder, Nova and Cinder Backup each use their own RBD pool and CephX identity, and where a test instance boots from a Ceph-backed volume. Each step ends with a check you can run before moving on.

Create separate pools for each service
Create one RBD pool each for Glance images, Cinder volumes, Nova ephemeral disks and Cinder backups, and initialize every pool for RBD use so that the block device tooling recognizes it. Keep the pool names and placement group settings in your design document, because each pool becomes a separate blast radius and a separate capacity line. Run the pool creation from a cephadm admin host, typically the engineer who owns the Ceph cluster. The step is done when the pool list shows all four pools, each with the RBD application enabled. Confirm the replication or erasure coding choice for each pool against your cluster design before you create them, since changing it later is disruptive.
Create one CephX user per service
Create a separate CephX user for Glance, Cinder, Nova and Cinder Backup, and grant each user only the capabilities its pool requires, using the RBD capability profile scoped to that pool. Nova compute nodes need access to the Cinder volume pool and the Nova ephemeral pool, while Glance should not be able to read volumes and Cinder Backup should not be able to write to the image pool. Store each keyring on the node that runs the matching service, with restrictive file permissions. The check is to list each key with its caps and confirm that the Glance key cannot list or open images in the volumes pool, for example by running an rbd ls against the wrong pool with that key and expecting a permission error.
Configure Glance for raw images and copy-on-write cloning
Set Glance to use the RBD store with the Glance pool and CephX user, and convert images to the raw format before upload, because copy-on-write clones only work from raw base images. Enable copy-on-write behavior in the RBD store settings as documented for your OpenStack release, and confirm the exact option names against the Ceph and OpenStack documentation for the release you deploy. Upload a small test image through the Glance client. The check is that the image appears in the Glance pool with rbd ls and that its format is raw, and that rbd info on the image shows the snapshot Glance creates for cloning.
Configure Cinder RBD backend and volume types
Add an RBD backend section to the Cinder configuration that points to the volumes pool and the Cinder CephX user, and set the RBD user and keyring path on the storage nodes that run cinder-volume. Create a Cinder volume type that maps to the backend so that users can select Ceph storage explicitly. Restart the Cinder volume service through your deployment tool. The check is that the volume service reports the backend as up in the Cinder service list, and that creating a 1 GB test volume results in an image object in the volumes pool visible through rbd ls. Delete the test volume afterwards to keep the pool clean.
Configure Cinder Backup to use Ceph
Point the Cinder backup service at the backups pool and its CephX user, using the Ceph backup driver so that volume backups are stored as RBD objects and can use incremental backups where the driver supports them. Confirm which backup driver options your Cinder release expects, because the names have changed across releases. Run the backup service on a node that has network access to the Ceph monitors and OSD public network. The check is to back up the test volume from the previous step and confirm that a backup object appears in the backups pool, then restore it to a new volume and verify the restored volume attaches cleanly.
Configure Nova libvirt RBD settings on compute nodes
On each compute node, set Nova's libvirt image type to RBD, point it at the Nova pool and CephX user, and make sure the libvirt secret for that user is defined so that qemu can authenticate to the cluster. Review the RBD cache settings and the exclusive lock option in the Nova and Ceph documentation for your release, and enable them deliberately, since exclusive locking affects how live migration behaves for RBD disks. Apply the change to one compute node first. The check is that the libvirt secret lists on that node and that virsh dumpxml on a test guest shows the RBD disk source with the expected pool and user.
Boot a test instance from a Ceph-backed volume
Create a test instance from the Glance image using a volume-backed boot disk, so that the root disk is a Cinder volume on Ceph, then start it on the compute node you configured. Also boot one instance with an ephemeral disk so you can see the Nova pool in use. Confirm that the instance reaches active status, reaches the network, and that rbd ls shows the root volume and the instance disk in the correct pools. Run a live migration test only after you have confirmed the exclusive lock and cache choices with your Nova release notes. This step closes the sequence when both instances run and their disks appear in the expected pools.

How pools, CephX users and OpenStack services map to each other

The core rule for this integration is one pool and one CephX identity per consuming service. Glance images, Cinder volumes, Cinder backups and Nova ephemeral disks should each live in their own RBD pool, and each service should authenticate with its own Ceph user holding only the capabilities that service needs. Glance, for example, needs write access to its image pool and read access to nothing else, while Cinder needs access to the volume pool and, separately, to the backup pool. Sharing one key across Glance and Cinder is common in early lab builds, but it widens the blast radius: a leaked keyring from an image service then grants write access to volumes, and a misconfigured capability on one pool quietly affects the other. Before the build starts, confirm the pool names, the CephX user for each service and the caps you intend to grant, and record them in the design document so the Ceph and OpenStack configurations stay in step.

Image-backed boots depend on a copy-on-write clone path. Glance stores each image as an RBD snapshot in its pool, and when Cinder creates a volume from that image or Nova builds an ephemeral disk, Ceph creates a clone that references the parent snapshot instead of copying the data. This only works across pools if the image is stored in the raw format. A QCOW2 image forces the consuming service to convert and copy the data first, which removes most of the speed and space benefit. Set the image format to raw at upload time, and make sure your image pipeline enforces it, because a single QCOW2 upload can go unnoticed until someone measures boot times. Keep Nova's RBD cache and exclusive lock settings on the compute nodes under review as part of the same change, since they determine how safely multiple clients touch the same image.

Human identity is a separate concern. Users sign in through Keystone, and federation over SAML 2.0 or OpenID Connect decides who can request storage, which projects they belong to and which roles they hold. Keystone mapping rules translate federated users into OpenStack groups and roles, but none of that changes the key a service uses to reach Ceph. Glance, Cinder and Nova authenticate to RADOS with their CephX users, which are service identities defined in Ceph and stored in the service configuration. Plan these two layers separately: a user removed from a Keystone group loses the ability to request volumes at once, while rotating a CephX key requires updating every node that holds it. Ask your identity team and your storage team to document both paths so an access review covers each.

Which OpenStack service uses which Ceph pool and key

This table maps each OpenStack service to its Ceph pool, CephX user, image format and cloning behavior, plus the Keystone model that gates volume creation. Replace every angle-bracket value with a name from your own design, since the names shown are placeholders and not recommendations. Use it as a checklist: if a row cannot be filled in for your cluster, resolve that design question before deployment.

Service	Ceph pool and CephX user	Format and cloning behavior	What to confirm
Glance images	Pool: <glance-pool>. CephX user: <glance-user> with read and write on the pool and read on the monitors.	Use raw images. Copy-on-write cloning from a protected snapshot lets new volumes and ephemeral disks start without copying the full image.	Confirm the Glance store backend setting and that the image snapshot is protected before cloning.
Cinder volumes	Pool: <cinder-volumes-pool>. CephX user: <cinder-user> with read and write on the volumes pool and read on the images pool so clones can run.	Raw volumes. Clones of Glance images are copy-on-write, so creation is fast when the image is in the same Ceph cluster.	Confirm the Cinder RBD driver settings and whether the volume type maps to the intended pool.
Nova ephemeral disks	Pool: <nova-vms-pool>. CephX user: <nova-user> with read and write on the VMs pool and read on the images pool.	Raw disks managed through librbd. Nova creates the disk from the Glance image using copy-on-write cloning.	Confirm the libvirt secret that holds the Nova CephX key on every compute node.
Cinder Backup	Pool: <cinder-backup-pool>. CephX user: <cinder-backup-user> with read and write on the backups pool only.	Backups are stored as RBD objects. Incremental backups depend on snapshots of the source volume in the volumes pool.	Confirm the backup driver and that the backup user cannot modify volume pools.
Keystone project and role model	Each project maps to its own Cinder volume type and quota. Only roles granted in the project can create volumes of that type.	Not applicable to Ceph directly. Volume type access controls which projects can place data on each Ceph pool.	Confirm which roles your policy grants for volume creation and how federated groups map to projects.
Compute node RBD settings	All compute nodes need the Nova CephX key in libvirt secrets and the same monitor addresses.	Enable RBD cache and exclusive locks in the client configuration. Cache sizing depends on memory per guest.	Confirm the client configuration on each hypervisor and test live migration after changing it.
Pool and key naming	Use names chosen by your team, such as <environment>-<service>-pool and <service>-<environment> for users.	Naming does not change behavior, but separate users per service keep caps narrow and audits clear.	Confirm that no service shares a user with another, and record each key owner.
Key rotation and access review	Each CephX key has a named owner who rotates it on a schedule your security policy sets.	Rotation requires updating Glance, Cinder, Nova and backup configuration together.	Confirm the rotation procedure, the rollback path and where keys are stored.

Securing the Ceph and OpenStack connection

Ceph and OpenStack share trust at several points: CephX keys held by each OpenStack service, the network that carries VM disk traffic, and the Keystone roles that decide who can create or delete volumes. Each card below is a control to design before the integration goes live, not after.

Least-privilege CephX caps per service

Give Glance, Cinder, Nova and Cinder Backup each their own CephX user, limited to the pools that service touches. A Glance key should not be able to read Cinder volumes, and a backup key should not be able to write to production pools. Ask for the exact caps each user receives, and review them after every pool change, since a broad cap copied from an example often outlives the project that needed it.

Keyring files readable by the service only

Each keyring file on a compute, controller or storage node should be readable only by the account that runs the service that uses it. Nova compute nodes hold keys that can reach VM disks, so a keyring left world-readable on a shared host exposes every attached volume. Check file ownership and mode on every node during rollout, and include keyring rotation in the runbook when staff leave or hosts are retired.

Messenger v2 secure mode

Ceph's messenger v2 protocol listens on port 3300 and its secure mode encrypts all traffic after authentication with AES-GCM and adds integrity checks. Enable secure mode for clients that support it, and confirm that each OpenStack node's Ceph client version uses it before relying on it. Older clients or legacy configuration may fall back, so verify the negotiated mode rather than assuming it.

Restricting the Ceph network to storage traffic

Place Ceph public and cluster traffic on dedicated VLANs or networks that OpenStack tenant networks, management interfaces and the internet cannot reach. Hypervisors and controllers should have a direct path to the monitors and OSDs but no route for tenant traffic into the storage fabric. Confirm the routing and firewall rules with the network team, and test that a tenant instance cannot reach the Ceph monitors.

Keystone roles for volume lifecycle

Cinder policy decides who can create, extend, delete or back up volumes, and Keystone roles are how that policy is expressed. Map roles to projects deliberately, so that a member role can use volumes but only an operator role can delete volumes that hold data. Keystone federation mapping rules can assign these roles from your identity provider, so review the mapping rules as part of the same change.

Isolating Cinder Backup targets

A Cinder Backup pool should use its own CephX user and pool, separate from the production volume key set, so that a compromised backup host cannot read or alter live volumes. Where backups are retained for long periods, ask whether the backup pool needs a separate failure domain and whether restores are tested from it. Confirm with your Cinder backup driver documentation which pool and user settings apply to your release.

Common failures when Ceph backs OpenStack storage

This table lists the failures teams most often hit when Ceph RBD backs Glance, Cinder, Nova and Cinder Backup, with the likely cause and a check to run first. Read each row as a triage path: confirm the symptom, run the check, then apply the fix. The main takeaway is that most failures trace back to keys, network reachability, image format, lock settings, pool capacity or host clock and DNS, and each can be verified on the node.

Symptom	Likely cause	Check to run	Fix
Volumes stuck in creating	The Cinder CephX key lacks caps on the volume pool	Run ceph auth get for the Cinder client and confirm it has rwx on the volumes pool	Update the client caps to cover the volume pool, then retry the volume create
Instances fail to start	libvirt on the compute node cannot reach the Ceph monitors on the storage network	From the compute node, test TCP reachability to the monitor addresses on port 3300 and 6789 and check the libvirt log	Route the storage network to compute nodes, correct monitor addresses in ceph.conf, and confirm the secret is defined in libvirt
Images copied instead of cloned	The Glance image is in qcow2 or another non-raw format, so Cinder cannot clone it copy-on-write	Run qemu-img info on the image and check the disk_format property in Glance	Convert the image to raw, re-upload it, and confirm that new volumes from it are created as clones
Live migration errors	Exclusive lock or RBD cache settings differ between compute nodes or conflict with the migration path	Compare the rbd cache and exclusive lock settings in ceph.conf across all compute nodes and check the image features with rbd info	Align client configuration on every compute node, then retest migration with a non-production instance
Backup jobs fill the production pool	Cinder Backup writes to the same pool as production volumes, or backups have no retention policy	Check pool usage with ceph df and list backup objects and their age in the backup pool	Give backups a separate pool with its own quota and retention, and confirm the pool's capacity headroom before scheduling jobs
Authentication errors on OpenStack or Ceph services	Clock skew or DNS differences between controllers, compute nodes and Ceph hosts	Check ceph health for clock skew warnings and compare date output and name resolution for monitor hostnames on each node	Synchronize time with the same NTP source everywhere and make monitor names resolve identically on all nodes
Glance uploads succeed but boots are slow	Images are not stored in Ceph as raw clones, so each boot copies full image data	Check the image's disk format and whether Nova boots from a Ceph clone rather than a local copy	Store images as raw in the Glance Ceph pool and confirm that Nova's image backend is set to Ceph

Questions buyers ask about Ceph and OpenStack integration

How much effort does a Ceph and OpenStack integration take?

Effort depends mainly on how ready the Ceph cluster already is and how many OpenStack services will consume it. A cluster that is healthy, sized and reachable from the compute and controller networks needs far less work than one still being designed. The main drivers are the number of services being connected (Glance, Cinder, Nova and Cinder Backup each need their own configuration), the number of compute nodes that must receive the client configuration and keyring, and how many pools and CephX keys the layout requires. Each additional pool and key adds review, testing and documentation. Ask any partner to show how they counted these items in the written scope.

How long does a Ceph and OpenStack integration take?

Duration follows scope. A narrow job that connects one or two services to an existing, healthy Ceph cluster is much shorter than a full layout covering Glance, Cinder, Nova and backups across a large compute fleet. Time is also shaped by change windows on production controllers and compute nodes, by how quickly the storage and cloud teams can review key and pool decisions, and by whether a test environment exists for validating live migration and volume attachment. Your partner should state the timeline as a dependency-based plan in the fixed-scope agreement rather than as a single promised date.

What does the integration need from our team?

Plan for three kinds of access and time from your side. The storage team needs administrative access to the Ceph cluster to create pools, CephX users and keyrings, and to confirm cluster health. The cloud team needs access to the OpenStack deployment tooling, configuration repositories and controller and compute nodes, along with a reviewer who understands how Glance, Cinder and Nova are configured in your environment. Both teams also need agreed change windows, because changes to Nova and Cinder configuration typically require service restarts. Confirm these responsibilities and access paths before work starts.

Can our own team set this up using the Ceph and OpenStack documentation?

Yes, a team with strong Ceph and OpenStack operations experience can follow the upstream documentation, which covers how OpenStack services use Ceph RBD. The harder parts are rarely the commands themselves. They are choosing a pool and key layout that matches your failure domains, deciding how raw images and copy-on-write cloning will affect your storage capacity, setting RBD cache and exclusive lock behavior for your compute nodes, and validating the result under load and during node failure. If your team lacks recent hands-on experience with either platform, a partner review of the design or a shared build can shorten the learning curve.

What recurring work follows the integration?

The integration creates ongoing work in three areas. First, CephX keys need a rotation practice, including who issues new keys, how the keyrings are redistributed to controllers and compute nodes, and how old keys are retired without breaking running virtual machines. Second, upgrades must stay aligned. OpenStack's cadence includes SLURP releases, which are the releases that support upgrades between SLURP releases as well as between adjacent releases. Ceph also publishes its own supported release lines with defined end-of-life dates. Each OpenStack or Ceph upgrade must be checked against the other platform's supported versions before it is scheduled. Third, capacity and pool growth need regular review as volumes, images and backups accumulate.

What should a fixed-scope quote for this integration list?

A fixed-scope quote should name the exact outcome and the boundaries around it. Ask for the list of OpenStack services in scope, with the Ceph pools and CephX users each one needs and the naming convention for them. It should state which Ceph and OpenStack versions are covered, which compute and controller nodes will be configured, and whether a test or staging environment is included. Look for the validation steps it commits to, such as volume creation, image upload and boot from volume, live migration checks and backup restore testing. It should also list buyer responsibilities, change windows, handover documentation and any ongoing support that is separate from the build.

What are the main risks to plan for in a Ceph and OpenStack integration?

The most common risks come from design choices made early and then hard to reverse. Using raw images without weighing the storage cost, or enabling copy-on-write cloning without understanding how base images are protected, can surprise capacity planning. Poorly scoped CephX keys can give services more access than they need. RBD cache and exclusive lock settings applied without testing can affect how volumes behave during failover or live migration. Finally, configuration drift between the controllers and compute nodes can cause intermittent attachment failures. Each risk should map to a named test or review step in the plan.

How to test the integration before users depend on it

Run a fixed set of acceptance tests before any project team builds on the platform. Upload a Glance image backed by the Ceph pool, boot an instance from it, and confirm the root disk lands in the Nova pool rather than on local hypervisor storage. Create a Cinder volume from the Ceph RBD backend, attach it to that instance, write data, take a volume snapshot, and restore it to a new volume. Then run a Cinder Backup to the backup pool and restore it to a clean volume. Finally, live migrate the instance between two compute nodes and confirm it keeps its disk and network state. Record the commands, the ceph pool names, and the exact OpenStack release used for each test so the results can be repeated after an upgrade.

Ask your team to confirm three things before the tests are signed off: that each compute node can reach the monitors and OSDs on the Ceph public network, that the CephX keys for Glance, Cinder, Cinder Backup and Nova have only the capabilities their service needs, and that copy-on-write cloning from Glance works, since a silent fallback to full image copies is easy to miss. Also confirm which Ceph release your cluster runs against the release your OpenStack cycle supports, because both sides have their own maintenance windows. The Ceph Releases page lists the currently maintained Ceph releases and their estimated end-of-life dates.

Ongoing operations need the same discipline. Have OpenStack dashboards or alerts read Ceph health, including HEALTH_WARN states, near-full OSDs and slow requests, so that a storage problem shows up as a warning before users see failed boots. Plan upgrades in order: move the storage side only when the OpenStack release you run is supported with that Ceph release, then move OpenStack, and retest the acceptance suite after each step. Keep a key inventory that lists every CephX user, its pool and its owner, along with where each key is stored. Without that inventory, rotating a key during an incident takes far longer than it should.

How the integration differs for Kolla-Ansible and OpenStack-Ansible

Kolla-Ansible deploys each OpenStack service in a Docker container, so Ceph client files reach a service through the Kolla configuration tree on the deployment host. Plan one Ceph configuration file and one CephX keyring per consuming service (Glance, Cinder, Nova and Cinder Backup), so each container mounts only the credentials it needs.

Configuration location: Per-service Ceph files are placed under the Kolla configuration directory, commonly /etc/kolla/config/, with subdirectory names set by the release you deploy.
Keyring scope: Create a separate CephX user for each service, which limits what a compromised Glance container can reach in the Ceph pools.
Nova and libvirt secret: Compute hosts need a libvirt secret that matches the CephX user Nova uses, so confirm how that secret is defined and injected.
Change path: Apply changes by running the reconfigure step for the affected services, not by editing files inside running containers.

Confirm the current file names, the reconfigure command and whether your release copies keyrings from the configuration tree in the 2026.1 deployment guides.

In an LXC-based deployment, OpenStack services run in system containers on controller and compute hosts, and the Ceph files must be visible inside those containers. The deployment repository is the usual source of truth, with Ceph settings supplied through user variables and host definitions under /etc/openstack_deploy, and the playbooks write the files into each container.

Variable-driven configuration: Ceph settings and keyring content are supplied as OpenStack-Ansible variables, so the deployment repository records which pool and CephX user each service uses.
Container boundary: Confirm whether the playbooks copy keyrings into each service container or whether you must define bind mounts for them.
Host-side libvirt: Nova compute and libvirt run on the host, so the CephX secret for Nova and Cinder must be defined where libvirt runs, even though the services themselves sit in containers.
Scoped runs: Limit playbook runs to the affected hosts or containers, and review which tags touch Ceph configuration before a production run.

Confirm the exact variable names, container paths and tags in the 2026.1 deployment guides before you write them into your repository.

On bare metal, OpenStack services run directly on the host, so Ceph configuration and keyrings sit on the host filesystem and are read by service processes with no container boundary. File ownership and permissions become the main control over which service can use which credential.

Host paths: Ceph client files are commonly kept in /etc/ceph on each host that runs a consuming service. Confirm the path the deployment uses for your release.
File permissions: Restrict each keyring to the service account that uses it, and check those permissions after every deployment run.
Client packages: Install the Ceph client libraries on each host that runs a consuming service, and keep their versions in step with the cluster as the cluster is upgraded.
Shared hosts: Where Nova compute and another consumer share a host, keep their keyrings separate so one service's credential cannot be read by another service's process.

Confirm the host paths, package names and permission model in the 2026.1 deployment guides and against your own hardening baseline.

What DeployOpen confirms in the written scope

DeployOpen plans and implements the Ceph and OpenStack integration inside your own infrastructure, under a written scope agreed before work starts. The scope is what makes the work checkable, so it should name the exact release targets on both sides. For Ceph, confirm whether the target is Tentacle (20.2.x) or Squid (19.2.x) and which point release will be deployed. For OpenStack, confirm the target release, such as 2026.1 Gazpacho, a SLURP release, or 2025.2 Flamingo, and whether the deployment uses Kolla-Ansible or OpenStack-Ansible. A scope that leaves these open will leave the upgrade path open too.

The scope should list each OpenStack service that will consume Ceph: Glance images, Cinder volumes, Cinder Backup and Nova guest disks, each with its own RBD pool and CephX user. Ask the written scope to state the pool names, placement group settings agreed with your Ceph design, the rbd_secret_uuid and key handling in the Cinder and Nova configuration, and whether the Glance image format is raw. It should also state the network design: which networks carry client traffic from compute nodes to the Ceph public network, how the messenger v2 secure mode is set, and how monitor addresses are published to the OpenStack hosts. Name the acceptance tests too, such as booting an instance from a Ceph-backed volume, live migrating it, and restoring a Cinder backup to a separate volume. Finally, the handover documentation should be listed as a deliverable, covering pool and key inventory, configuration files and the runbook your team will use after go-live.

How DeployOpen delivers Ceph and OpenStack integrations

DeployOpen plans, implements, documents and supports Ceph and OpenStack integrations inside your own data centers or cloud accounts. Each engagement starts with a written scope that fixes the pools, CephX users, OpenStack services and acceptance tests before any configuration changes are made.

How we scope

Written scope lists which of Glance, Cinder, Nova and Cinder Backup will use Ceph RBD.
Pool layout, placement group planning and CephX key separation per OpenStack service are agreed up front.
Engagements are fixed-scope, with deliverables and timelines confirmed in writing before work starts.

How we build

Pools, CephX users and keyrings are created and tested against each OpenStack service before cutover.
Glance image format, copy-on-write cloning and RBD cache settings are configured and checked on compute nodes.
Exclusive lock and live migration behavior are validated on your hypervisor and Ceph versions.

How we hand over

Handover includes configuration records, key ownership notes and the verification results for each service.
Runbooks cover volume creation, image upload, backup restore and the steps for rotating CephX keys.
Your team receives a list of open items, such as hardware or network changes still needed before production use.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Retainer work can cover Ceph and OpenStack upgrade planning against the supported release cycles you run.
Ask for the support boundary in writing, including which Ceph and OpenStack versions and environments it covers.