OpenStack Ceph storage integration guide

How OpenStack Ceph storage integration backs Glance, Cinder and Nova

If you run or plan an OpenStack cloud and need shared block storage for image handling, volumes, backups and VM disks, Ceph block devices (RBD) can serve all four roles. Glance images, Cinder volumes and backups, and Nova guest disks can all live on Ceph, so virtual machines can boot from Ceph without local storage on the hypervisor. That shared model is what makes live migration, host replacement and volume reattachment practical, and it is the reason most teams evaluate Ceph before they buy a storage array for OpenStack. The integration is harder than the reference diagram suggests. Glance, Cinder and Nova each authenticate to Ceph with their own cephx credentials and usually write to their own pools, so a mistake in one key's capabilities or pool assignment shows up as a failure in a different service. Boot-from-volume and Cinder backups also change failure behavior. A VM whose root disk is a Ceph volume depends on the storage network and the Ceph cluster for every read and write, so a storage incident becomes a compute incident. Backups add a second dependency that often runs on a different schedule and network path, which should be tested separately. Storage and compute capacity must be sized together. Every new hypervisor adds guest I/O against the same OSDs, and Ceph replication multiplies raw capacity needs. Ask for the replication or erasure-coding model, the expected IOPS and throughput per tenant class, and the headroom needed to recover from a failed OSD or host without saturating the network. Ceph cluster design, including CRUSH rules, failure domains, placement groups and networking, is a separate skill from OpenStack configuration. Confirm that your team or partner has both before committing to a design. Before you pick versions, confirm the release pairing between OpenStack and Ceph in both projects' documentation. Check the OpenStack release you plan to run against the Ceph release listed in the Ceph documentation for OpenStack integration, and confirm that the client libraries installed on the controllers and compute nodes match. Record the pairing in your change plan, because it constrains the order of future upgrades on both sides. Finally, decide what you will test before go-live. At minimum, verify image upload and boot from Glance and Ceph, volume create, attach and detach through Cinder, a VM boot from a Ceph-backed volume, a Cinder backup and restore, and a planned OSD or storage node failure during active I/O. Each test should have a named owner and a pass condition agreed in writing. Without that list, the first real test tends to be an incident.

Which OpenStack and Ceph components carry the integration

The Ceph integration is spread across several OpenStack services, each with its own Ceph pool, client identity and configuration. Knowing which component owns which piece tells you where to look when storage behaves unexpectedly and where changes must be made consistently across the fleet.

Ceph RBD pools

Each service that stores data in Ceph needs its own RBD pool so that capacity, replication settings and access can be managed separately. Typical splits cover images, volumes, backups and ephemeral guest disks. Confirm the pool names, placement group sizing and replication policy with your Ceph administrator before any OpenStack service is pointed at them, because changing pool layout later is disruptive.

Cephx client users per service

Each OpenStack service authenticates to Ceph with its own cephx client user, granted capabilities only on the pools it needs. Sharing one client key across Glance, Cinder and Nova widens the blast radius of a leaked credential. Check the capability strings for each user during review and confirm how the deployment tooling generates and distributes these keyrings to controllers and compute hosts.

Glance store configuration

Glance writes image data to the Ceph images pool through its RBD store driver, so the service's configuration file must name the pool, the cephx user and the Ceph configuration path. Verify that the image format and copy-on-write settings match what Nova and Cinder expect, since a mismatch surfaces later as slow boots or failed clones. Locate these options in the deployment tooling's Glance role or variables.

Cinder RBD backend and backup driver

Cinder exposes Ceph volumes through an RBD backend section, and its backup service can use a separate Ceph driver to write volume backups to a dedicated pool. Treat these as two configurations: a failure in the backup path should not be mistaken for a volume attach problem. Confirm which backend names are exposed as volume types and where the backup pool and user are declared in your tooling.

Nova libvirt RBD settings

Nova's compute service must be told to place ephemeral guest disks in Ceph and to use the correct cephx user when libvirt connects. These settings live in the compute configuration and affect whether instances can boot from Ceph without local hypervisor storage. Check that the image backend option, the pool name and the rados user agree with the Glance and Cinder configuration before rolling the change across compute nodes.

Libvirt secret on each compute host

For libvirt to authenticate to Ceph, every compute host needs a libvirt secret that holds the cephx key, identified by a UUID that the Nova configuration references. Missing or mismatched secrets are a common cause of instances failing to start on only some hosts. Confirm how the deployment tooling defines this UUID, distributes the key, and re-applies the secret when a compute node is added or rebuilt.

Pool design for OpenStack Ceph storage integration: which trade-offs to settle first

This table compares the four storage layout decisions that shape OpenStack on Ceph: pool layout, boot source, backup target and cluster placement. Read each row for its operational consequence, such as blast radius, capacity planning, recovery time or the number of keys to rotate. Settle these choices before the first Glance image is uploaded, because changing them later usually means data migration.

Decision option	When it fits	Operational consequence
One pool per service	Clear separation is needed between Glance, Cinder and Nova, or each service has different replication or capacity needs	More pools to size, monitor and balance. A fault or full pool affects only that service, and each pool needs its own placement group planning and capacity alerts.
Shared pools with namespaces or separate Cephx users	Fewer pools are wanted and teams accept a shared capacity pool with access limited by user caps	Lower pool count, but capacity exhaustion affects every consumer. Each service needs its own Cephx key, so rotation and revocation involve more keys to track.
Boot from volume	Instances need persistent root disks, fast live migration or the ability to recreate a compute node without losing guest data	Root disks become Cinder volumes in Ceph, so the cluster carries more I/O and capacity load. Recovery depends on volume and snapshot procedures, and Cinder and Ceph both become critical to restore.
Ephemeral Nova disks on Ceph	Workloads are stateless or rebuilt from images, and fast instance creation matters more than keeping the root disk	Guest disks live in a Ceph pool managed by Nova. Losing the compute node loses the instance state, so recovery relies on images and application-level data, not Cinder snapshots.
Cinder backups to a Ceph pool	A separate Ceph backup pool is acceptable and recovery within the same cluster is the priority	Backup and production data share failure domains. A cluster-level incident can take out both, so confirm whether a second copy or an off-cluster target is required by your recovery objectives.
Cinder backups to an external target	Backups must survive loss of the Ceph cluster or meet separate retention and access controls	Adds a second system to operate, secure and monitor, and network throughput to the backup target becomes a sizing input. Restore times depend on that link, so test restores at realistic volume sizes.
Hyperconverged Ceph with compute	Hardware budget favors fewer machines and the fleet is small enough that storage and compute can share failure domains	Compute and storage compete for CPU, memory and network. A host failure removes both guest capacity and storage OSDs, which increases rebuild load during the same event.
Separate Ceph cluster	Storage must scale independently of compute, or several compute clusters will share one storage backend	Adds hardware, network fabric and an independent operations plan. Capacity planning and upgrades for storage happen on their own schedule, and failure domains are cleaner.
Keys and access to rotate	Every decision above creates Cephx users and secrets in Glance, Cinder and Nova configuration	Count keys per service and per pool before go-live. Each rotation touches the configuration of every service that holds the key, so document the list in version control.

Build order for OpenStack Ceph storage integration, step by step

This sequence takes an OpenStack cloud from a verified release pairing to a Ceph backend that serves images, volumes, backups and instance disks. Each step ends with a check that the next step depends on, so problems surface while they are still small. The platform team owns the OpenStack configuration and the storage team owns the Ceph cluster throughout.

Confirm the release pairing in both documentation sets
Before any configuration, the platform team records the OpenStack release and the Ceph release the cluster will run. They then check each component version, including Glance, Cinder and Nova, against the Ceph integration notes in the OpenStack documentation and the matching Ceph documentation for that release. Record the decision in the design document with the author and date. This step closes when a signed-off pairing sheet lists every component version and the documentation page each one was checked against. If a combination is not documented, resolve it with the vendor or upstream before creating any pool.
Establish the Ceph health baseline
Capture the state of the Ceph cluster before OpenStack writes any data, so later problems can be traced to the integration or to faults that already existed. The storage engineer runs the cluster status command and records monitor quorum, OSD counts, placement group states and capacity. Save the output with the change ticket and document any warning present at baseline, with an owner and a plan. The step closes when the status read reports health OK, or when every remaining warning has been accepted in writing and the team understands its cause.
Create pools and least-privilege cephx users
Create a separate RBD pool for each consumer, typically images, volumes, backups and ephemeral instance disks, and enable the RBD application tag on each one. Create one cephx user for Glance, one for Cinder, one for the Cinder backup service and one for Nova. Grant each user only the capabilities its service needs on its own pool, and confirm the exact caps in the Ceph and OpenStack integration documentation for your release. Pool names, placement group counts and replication settings should come from the sizing decision made earlier. The step closes when a review of the user list shows no service can write to another service's pool, and a test write from each keyring to its own pool succeeds.
Configure Glance and upload a test image
Point the Glance RBD store settings at the images pool, then deploy the Ceph configuration file and the Glance keyring to every controller host that runs the image service. Before choosing the image format, confirm in the Ceph documentation whether your release requires raw images for copy-on-write cloning. Restart the image service and upload a small test image. The step closes when the checksum of the image read back from the store matches the checksum of the source file, and the image object appears in the images pool.
Configure Cinder and verify a test volume
Add a Ceph RBD backend to Cinder that uses the volumes pool and the Cinder keyring. Configure the backup driver to use the backup pool and the backup keyring, then restart the volume and backup services. Create a test volume, attach it to a test instance, write a known data pattern, and detach it. The step closes when the volume reaches the expected status, the attach succeeds, and a test backup restores to a new volume with matching content.
Configure Nova libvirt RBD on compute hosts
On each compute host, set the Nova libvirt configuration to store ephemeral disks in RBD, define a libvirt secret that holds the Nova cephx key, and set the secret UUID that Nova references. Confirm first that every compute host can reach the Ceph monitors and OSDs over the storage network. Apply the change to one canary host, check it, then roll it across the rest of the fleet in batches. The step closes when a test instance boots with its root disk in the ephemeral pool and the secret is defined on every compute host.
Enable boot-from-volume and test migration and evacuation
Confirm the flavor and API settings your release needs for boot-from-volume, then boot a test instance from a Cinder volume created from a Glance image. Run a live migration between two compute hosts, and then evacuate an instance from a host taken out of service, both inside a maintenance window agreed with the operations team. Record migration timings and any errors. The step closes when the instance boots from a Ceph volume, keeps its disk contents and network connectivity through live migration, and returns to service on another host after evacuation.

How the integration differs by OpenStack deployment tool and Ceph placement

Kolla-Ansible deploys OpenStack services as Docker containers driven by Ansible. For Ceph, the practical question is how keyrings and configuration files reach the containers that need them. Glance, Cinder, Nova and any backup service each authenticate to the cluster with their own Cephx identity, so each one needs a defined path to its key.

Configuration source: Monitor addresses, keyrings and pool names are typically supplied through the deployment inventory and global settings, so they belong in version-controlled files with the rest of the cluster definition.
Per-service identities: Each consuming service usually runs as its own Ceph client with access limited to its pools. Confirm the client naming and capability settings your release expects.
Container mounts: Keyrings and config files are mounted into containers, so host file paths and permissions determine who can read them. Check how the chosen release sets ownership inside the container.
Key rotation: Rotating a Cephx key means updating the inventory and redeploying the affected containers, so plan it as a change with a restart window.

Before you write the first pool definition, confirm in the 2026.1 Kolla-Ansible guide how keyrings are provided and whether your inventory layout matches it.

What drives the effort and cost of Ceph integration for OpenStack

This table lists the factors that change how much work a Ceph integration takes and who carries each part of it under a fixed-scope engagement. Read each row as a question to answer before scoping, then use the quote checklist to confirm the written scope covers it. The main takeaway is that the existing Ceph state, the data to move and the number of environments usually move cost more than the OpenStack wiring itself.

Driver	How it changes the work	How to keep it down
Existing Ceph cluster or greenfield build	An existing cluster adds health checks, capacity review, pool audits and change windows on a live system. A greenfield build adds cluster design and bootstrap work, which the client may or may not include in scope.	Confirm in writing whether the Ceph cluster is in scope, who operates it today, and whether a healthy baseline report is a deliverable.
Number of pools and OpenStack services to wire	Each pool for Glance, Cinder, Nova ephemeral disks and backups needs its own design, cephx capabilities, client keys and configuration. More pools and services mean more testing paths.	Agree a fixed list of pools and services up front and keep additional pools as a priced change request.
Compute hosts that need the libvirt secret	Every hypervisor that runs Nova with Ceph needs the libvirt secret and matching client configuration. Host count multiplies rollout, verification and rollback steps.	Standardize host groups in the deployment inventory so the secret is distributed by automation and checked per host group.
Data volume to migrate or import	Moving existing images or volumes into Ceph requires copy time, bandwidth planning, checksum verification and a cutover plan. Volume size and count drive the migration method more than the integration itself.	Inventory images and volumes first, separate what must move from what can be recreated, and ask for the migration method to be named in the quote.
Backup retention and restore testing	Retention periods set the Ceph capacity and backup schedules. A restore test for each backup target adds verification work that is easy to leave out of a quote.	Set retention with the data owners, then ask whether restore tests are included, how many, and who signs off the results.
Network separation between storage and tenant traffic	Separate storage and cluster networks add VLANs, routing, MTU checks and firewall rules across hosts and Ceph nodes. Shared networks add tuning and QoS work and a higher risk of noisy-neighbor effects.	Decide the network design before scoping and ask the quote to state which network segments are in scope and who provisions them.
Number of environments (lab, staging, production)	Each environment repeats the build, configuration, testing and documentation steps. Keeping configuration identical across environments adds automation work but reduces rework at production cutover.	Build the lab first, promote the same automation to staging and production, and ask whether each environment is a separate line item.

How to test that Ceph-backed OpenStack storage works and fails safely

Test the Ceph-backed OpenStack storage before any tenant depends on it, and write down the expected result of every test before you run it. A test that passes because nobody defined what passing means proves little. For each case, record the service involved (Glance, Cinder, Nova or the Ceph cluster itself), the action, the expected outcome, the observable evidence you will collect, and the owner who signs off. Keep this matrix under version control next to the deployment configuration so that it can be rerun after an upgrade, a Ceph expansion or a change to the pool layout.

Start with functional tests, one service at a time, and then combine them. Upload an image to Glance and confirm it lands in the expected RBD pool and boots a Nova instance. Create a Cinder volume, attach it to a running instance, write a known data pattern, detach it, reattach it and confirm the pattern is intact. Take a snapshot, create a new volume from that snapshot and compare checksums. Boot an instance from a Cinder volume (boot-from-volume) and confirm the guest disk is backed by Ceph rather than local hypervisor storage. Then run live migration between two compute hosts and, separately, evacuate instances from a host you have deliberately powered off, and confirm both preserve the disk contents. Each of these tests should name the exact compute hosts, pools and images used so that the results are reproducible.

Backup and restore need the strictest check. Back up a volume with Cinder's backup service, restore it to a separate volume (not over the original) and verify the restored data by reading it, typically by comparing checksums of files or a known record set against the source. A restore job that reports success only shows that the job finished. Treat a restore as passed only when the data matches, and make the test fail if the restored volume is attached to the wrong instance, is empty or differs from the source. Confirm the backup target and retention settings with your Cinder and Ceph administrators before the test, because they determine where the data is stored and how long it stays there.

Failure tests show whether the integration fails safely, which is a different question from whether it works. In a non-production Ceph cluster, stop one OSD and observe how client I/O behaves: latency, whether cluster health moves to a degraded state, how long recovery takes and whether guest filesystems remain consistent. Then stop one monitor and confirm that the remaining quorum keeps serving requests. Next, revoke one cephx key used by a single service, such as the Cinder or Glance user, and confirm that the affected service refuses operations with a clear authentication error instead of falling back to a broader credential. Record which operations fail, which keep working and what the logs show. Ask your Ceph administrator which failure domains and recovery settings apply to your cluster, since the results depend on them.

Finally, decide in advance what a failed test means for release. A failed restore or a fallback to an overly broad key should block go-live, while a slower recovery than expected may only require a documented change to the operating procedure. Agree these thresholds with the platform owner before testing starts, and keep the signed-off results with the change record. If your organization needs independent assurance, the test evidence can support an external assessment, but the assessor, not the test team, decides whether the controls are adequate.

Securing cephx keys, libvirt secrets and storage traffic

Ceph gives OpenStack a shared storage layer, so its credentials and network paths become a single point of exposure. The six controls below cover who holds keys, where secrets live, how they change, which networks reach the cluster and how backups stay separate. Confirm each one against the Ceph documentation for your release before signing off the design.

One cephx user per service

Give Glance, Cinder and Nova each their own cephx identity, with capabilities limited to the pools that service uses. A shared admin key lets a compromised service read every image and volume in the cluster. Review the capability strings against the Ceph documentation for RBD access, and confirm the current syntax for your Ceph release before generating keys. Check each service configuration to confirm that pool names point only to pools that identity should reach.

Secrets kept out of plain configuration

Keep keyring contents and libvirt secret values out of playbooks, inventories, images and version control. Store them in the deployment secrets store your team already operates, and confirm the deployment tooling reads them at run time without leaving rendered copies on hosts. Check file ownership and permissions on Ceph keyring and configuration directories, and confirm that the repository holds references to secrets, never the values themselves.

Libvirt secret limited to compute hosts

Nova on compute hosts uses libvirt to attach Ceph-backed disks, so the libvirt secret holding the cephx key is needed only there. Define the secret on compute hosts that run Ceph-backed guests, and nowhere else. Confirm the secret UUID matches the value in the Nova configuration on every compute host, and verify that hosts outside the compute group cannot list or read it. Also confirm who can reach the libvirt management interface on each host.

Rotating keys and what it interrupts

Rotation replaces cephx keys and libvirt secret values on the schedule your security policy sets. A safe order adds the new key in Ceph, updates the secrets store, restarts or reloads the services and compute hosts, and removes the old key last. Expect interruption where a service reads its keyring only at start, and confirm with your release whether running guests pick up a changed secret without a restart. Rehearse the full sequence in a non-production cluster first.

Isolating Ceph networks from tenant traffic

The Ceph public network carries client traffic from OpenStack services and compute hosts, and the cluster network carries OSD replication and recovery traffic. Place both on dedicated interfaces or VLANs that tenant networks cannot route to, and keep Ceph daemons off tenant overlay networks. Confirm firewall rules allow monitor, OSD and manager traffic only from known client subnets, and check the network settings for your release against the Ceph documentation.

Protecting backups with separate keys

Backups of Glance images, Cinder volumes and Nova disks should use their own cephx identity and their own encryption keys, separate from the keys that run production. A compromise of the production path should not allow an attacker to read or delete backups. Confirm where backup encryption keys are held, who can access them, and how restore tests authenticate. Ask whether any backup copies also sit outside the Ceph cluster.

What to monitor, back up, upgrade and document after go-live

After go-live, the Ceph cluster and the OpenStack services need one shared view. Watch Ceph health, OSD states, placement group states and raw capacity alongside the Nova, Cinder and Glance service status, so that a storage warning is read in the context of the compute workloads that depend on it. Track usage per pool, at minimum the pools that hold Glance images, Cinder volumes, Nova ephemeral disks and any backup target, and compare their growth with the rate at which instances and volumes are being added. Ask your team to agree on the thresholds that trigger a capacity review before go-live, and confirm that the alerts reach the people who can act on them outside business hours.

Back up two things on a schedule. The first is the Ceph configuration and its keyrings, which the cluster cannot rebuild from its own data. The second is the OpenStack configuration that references pools, users and keys, including the RBD sections of the Glance, Cinder and Nova configuration files and any backup driver settings. Store both copies outside the cluster and keep them under change control. A backup that has never been restored is an assumption, so schedule restore tests that recover a Cinder volume to a scratch pool and boot an instance from a restored Glance image. Record the date, the scope, the time taken and any gap found, and treat a failed restore as a change request, not a footnote.

Plan upgrades against the SLURP-aligned cadence rather than against individual point releases. OpenStack 2026.1 Gazpacho, a SLURP release, was released on 2026-04-01, and 2025.1 Epoxy, also SLURP, was released on 2025-04-02. The 2027.1 Indri release, also SLURP, is in development with an estimated date of 2027-03-24. Stable branches are maintained for approximately 18 months, so an OpenStack release that leaves that window stops receiving fixes. Before each OpenStack step, confirm with the Ceph release notes and the OpenStack release documentation that the target pairing is supported, and sequence Ceph and OpenStack upgrades as separate, tested changes with a rollback point for each.

Hand over a documentation set that an engineer who did not build the integration can follow during an incident. It should contain a pool map listing each pool, its purpose, its replication or erasure coding settings and the services that use it; a key inventory listing each Ceph user, its capabilities and the systems that hold its keyring; and a register of config locations on every controller and compute node. Add runbooks for replacing a failed OSD and for rotating Cephx keys without interrupting attached volumes, and keep a restore record for every test. Review these documents at each upgrade, because a pool map that no longer matches the cluster is worse than none.

Questions teams ask before they build Ceph storage for OpenStack

Can our team build Ceph storage for OpenStack without a partner?

Yes, a team with working Ceph and OpenStack operations experience can build this in-house. The work covers separate pools for Glance images, Cinder volumes and Nova guest disks, a cephx client key for each service, OpenStack service configuration, a backup target, and a test plan for instance creation, live migration and failure cases. The hard parts are usually pool sizing against failure domains, the network layout for replication traffic, and keeping the configuration correct through later upgrades. Teams without recent Ceph experience often bring in a partner for design review and first deployment, then operate the result themselves. Whichever route you take, name who owns the Ceph cluster after handover.

What drives the cost of Ceph storage integration for OpenStack?

The main cost drivers are how many OpenStack services consume Ceph, whether the Ceph cluster already exists or is built as part of the work, how many pools and failure domains the design needs, and how many hosts must be reconfigured. Network changes, backup target design and the test matrix add effort. Costs fall into one-time design, build and validation, and recurring work such as Ceph and OpenStack upgrades and capacity growth. DeployOpen plans and implements these engagements under a fixed scope agreed in writing, and does not publish a price list. Ask for a quote that lists each deliverable, the environments covered, the recurring support you need, and what is excluded.

How long does a Ceph and OpenStack storage integration take?

The duration depends on the factors that set the pace, not on a fixed number. The biggest are whether a Ceph cluster exists and is healthy, how much network and hardware work is needed, how many compute and controller hosts must change, how many OpenStack services use Ceph, and how many test scenarios the change window requires. Change approval cycles and access to lab or staging hardware also set the schedule. Most engagements are fixed-scope, so the timeline is agreed in writing alongside the deliverables. Ask any provider for a schedule that lists dependencies on your team, such as access approvals and maintenance windows.

What do we need to provide for a Ceph storage integration project?

You need administrative access to the Ceph cluster, or a named Ceph operator who can run commands and share health output, plus access to the OpenStack controller and compute hosts in your infrastructure. Network access to the Ceph public and cluster networks and a maintenance window for compute and controller changes are also required. Name one owner with authority to decide pool design, sizing and cutover, and a backup contact for approvals. Share current Ceph and OpenStack versions, a hardware inventory, and your rules for keyrings and secrets. Confirm which access paths your change process allows before the scope is signed.

Can we reuse an existing Ceph cluster for OpenStack storage?

Often yes, but only if the existing cluster has healthy capacity and a layout that suits this use. Check that its Ceph release is supported with the OpenStack release you plan to deploy, that free capacity covers the planned pools, and that its failure domains match the hosts. Consider whether sharing the cluster with other applications would affect latency and capacity for these workloads. Reuse means new client keys, separate pools for each service, and no changes to existing data. Review the cluster's performance history before you commit, and confirm version pairings against the current Ceph and OpenStack documentation.

Is boot-from-volume required when using Ceph with OpenStack?

No, boot-from-volume is optional. Ceph can back Glance images, Cinder volumes, backups and Nova guest disks, and Nova can run instances with their disks on Ceph without local hypervisor storage. Boot-from-volume makes the root disk a Cinder volume, which can simplify recovery and moves, but every boot then depends on the storage network and the Ceph cluster. Many teams keep ephemeral disks on Ceph for general workloads and use boot-from-volume for stateful ones. Decide per flavor or workload class, and test live migration, evacuation and snapshot behavior for each choice before production.

How does the Ceph integration differ between Kolla-Ansible and OpenStack-Ansible?

The Ceph design stays the same, but the deployment steps differ. Kolla-Ansible deploys OpenStack services in Docker containers with Ansible, so Ceph client configuration and keyrings reach the service containers through its configuration layout. OpenStack-Ansible deploys in LXC containers or on bare metal, so the same settings are set through its inventory and role variables, and the host layout differs. Confirm which method you use, because upgrade procedures, configuration paths and troubleshooting commands vary between them. Verify the exact variable names and key distribution steps in the deployment guide for your release.

Which Ceph pools should we create for Glance, Cinder and Nova?

Use separate pools for images, volumes, ephemeral disks and backups, each with its own client key, so access and quotas can be controlled independently. Set replication or erasure coding per pool based on durability needs and capacity overhead, and align the CRUSH rules with failure domains such as host or rack. Tag each pool for RBD use and check placement group counts before loading data, because changing them later is disruptive. Document the expected growth for each pool and have the sizing reviewed by someone who has run the cluster under load. Test a failed host or disk in a non-production environment before the first production workload arrives.

How DeployOpen scopes, builds and hands over Ceph storage integration

DeployOpen plans, implements, tests, documents and supports OpenStack Ceph storage integration inside your own data centers or cloud accounts. Engagements are fixed-scope, so the pools, backends, backup targets and acceptance tests are agreed in writing before the build begins.

How we scope

The written scope names which of Glance, Cinder, Nova and backups will use Ceph block devices.
It records the pool layout, replication or erasure coding choices, and placement of Ceph nodes alongside compute.
It lists boot-from-volume requirements, instance placement and the Ceph version and OpenStack release in use.

How we build

Configure Glance, Cinder and Nova RBD backends in the deployment tooling your team already uses.
Create Ceph pools and client keys with the minimum capabilities each OpenStack service needs.
Test image upload, volume creation, live migration and instance boot from Ceph before sign-off.

How we hand over

Deliver configuration in version-controlled form, with pool, key and backend settings documented.
Provide runbooks for backup and restore of volumes, images and Ceph pools, including test restore results.
Walk your operators through capacity checks, failure scenarios and the acceptance tests performed.

How we support

Ongoing support is available as a retainer covering Ceph and OpenStack storage configuration changes.
Upgrade planning checks Ceph and OpenStack compatibility before each OpenStack release is adopted.
Confirm with your storage vendor and Ceph release notes which versions your cluster supports.

OpenStack Ceph storage integration