Connecting OpenNebula datastores to Ceph RBD
An OpenNebula cluster that needs shared block storage for VM images and disks can back those datastores with Ceph RBD. The Ceph datastore driver stores images and disks in Ceph, and every node that runs them must act as a Ceph client. Before any datastore is created, confirm that each hypervisor and front-end node can reach the Ceph monitors, holds the right client keyring, and has the Ceph client packages it needs, because a missing client on one host shows up later as a failed deployment rather than a clear error.
The image datastore is the entry point. It is defined with DS_MAD = ceph and TM_MAD = ceph, and the disks it hosts use DISK_TYPE = RBD, so each image becomes an RBD image in a pool you name. The system datastore, where running VM disks live, offers a real choice. In full Ceph mode disks stay in RBD for the life of the VM. In SSH mode each disk is exported to the hypervisor's local file system, which does not support disk snapshots. The decision therefore depends on whether your operators depend on snapshots for running VMs, and it should be settled before the first template is deployed. The OpenNebula Ceph datastore documentation describes both modes and the attributes that set them.
Use RBD format 2 for the images, which the OpenNebula documentation strongly recommends. Format 2 supports the features that copy-on-write cloning and snapshots rely on, so creating the pools with the expected image format is a step to verify on the Ceph side rather than assume. Ask your team to document the pool names, the Ceph user per datastore, and the system datastore mode in the same change record, because these settings are hard to change once VMs run on them.
What you need before configuring the Ceph datastore
A Ceph datastore for OpenNebula depends on work that happens outside OpenNebula: a healthy Ceph cluster, a pool and CephX identity reserved for OpenNebula, and hypervisor nodes that can reach the monitors. Confirm each item below before you touch the datastore template, because most failed datastore attachments trace back to one of them.
Ceph cluster and pool readiness
Confirm the cluster reports healthy and has a pool reserved for OpenNebula images and system disks. Check the Ceph release you run against the active releases page, since the Tentacle and Squid lines have different end-of-life dates. Ask whether the pool will be replicated or erasure coded, because that choice affects the datastore configuration later.
Ceph client packages on each node
Every OpenNebula node that runs VMs must act as a Ceph client, so each hypervisor needs the Ceph client packages that match your cluster release. Install them the same way on every node and record the versions. Mixed client versions across hypervisors are a common source of hard-to-reproduce mapping errors.
CephX user and keyring distribution
Create a dedicated CephX user with capabilities limited to the OpenNebula pool, rather than reusing the admin key. Place the keyring on each hypervisor with restrictive file permissions and document who can rotate it. Plan the rotation procedure now, because changing the key later means updating every node at once.
Network reachability to monitors
Each hypervisor must reach the Ceph monitors and the OSD hosts on the ports Ceph uses, including the msgr2 port 3300 when you use it. Test name resolution and routing from every node, not only from one host. Confirm that firewalls and security groups allow the same paths on storage bridge nodes if you plan to use them.
OpenNebula version and driver fit
Record the OpenNebula version you run. The current latest tag in the repository is 7.4.1, so confirm the release line you deploy against before reading driver options. Check the Ceph datastore page for your version, because transfer modes and parameters can differ between releases.
Storage bridge node decision
Decide early whether any node will act as a bridge between OpenNebula and Ceph, and who will operate it. Bridge nodes add a failure point and a patching obligation, so confirm their sizing and monitoring before adding them. If your hypervisors can all reach Ceph directly, you may not need one at all.
How to configure the Ceph datastore step by step
This sequence takes an OpenNebula environment from a Ceph cluster with no OpenNebula integration to working image and system datastores backed by RBD, verified by a full test VM lifecycle. Each step ends with a check you can run before moving on.
Confirm prerequisites and the Ceph cluster baseline
Before touching OpenNebula, confirm that the Ceph cluster is healthy and that the OpenNebula front-end and hypervisor nodes can reach the Ceph monitors on the network you intend to use. Check the OpenNebula Ceph datastore documentation for the versions of OpenNebula and Ceph you run, and confirm the Ceph release is one still receiving maintenance fixes. Your Ceph administrator runs the health check and records the monitor addresses. This step is complete when
ceph -sreports HEALTH_OK (or an understood warning) and each hypervisor can reach the monitor ports from the command line.Create a dedicated RBD pool and CephX user
Your Ceph administrator creates a separate RBD pool for OpenNebula, initializes it for RBD use, and creates a CephX user limited to that pool with the capabilities the OpenNebula Ceph datastore documentation requires. Keep this user separate from any other platform so you can rotate or revoke it without affecting other workloads. Export the keyring and store it in your secrets process, not in a shared file. This step is complete when the new user can list and write objects in the OpenNebula pool and cannot access other pools, which you can test with a scoped
rbdcommand.Distribute keys and ceph.conf to all nodes
Copy the Ceph configuration file, the CephX keyring for the OpenNebula user, and the required libvirt secret material to the OpenNebula front-end and every hypervisor node that will run VMs from this datastore. Set file ownership and permissions so the OpenNebula service account can read them and no other local account can. Define the libvirt secret on each hypervisor so that libvirt can authenticate to RBD. This step is complete when each node can run
rbd lsagainst the pool using the OpenNebula identity and libvirt lists the secret.Define the Ceph image datastore
In OpenNebula, create an image datastore with DS_MAD set to ceph and TM_MAD set to ceph, and set DISK_TYPE to RBD. Point it at the pool and user you created, and set RBD format 2 as the documentation recommends. Assign the datastore to the cluster that contains your hypervisors. This step is complete when the datastore shows as enabled in Sunstone or the CLI, and a test image registered from a small raw disk appears as an RBD object in the pool.
Define the system datastore in Ceph or SSH mode
Create a system datastore and choose full Ceph mode or SSH mode. In full Ceph mode, VM disks are created directly as RBD images and snapshots are available. In SSH mode, each disk is exported to the hypervisor local file system, which does not support disk snapshots, so confirm with your team whether snapshots are a requirement before choosing it. Attach the system datastore to the same cluster. This step is complete when the datastore reports enabled and the mode you selected is recorded in the datastore template for your change record.
Optionally add an erasure-coded data pool
If storage efficiency matters more than peak I/O, add EC_POOL_NAME to the image datastore template to point at an erasure-coded data pool. The OpenNebula documentation notes that erasure coding saves space but usually reduces I/O performance, so benchmark representative workloads before using it for production disks. Your Ceph administrator must create the erasure-coded pool with the correct profile and allow overwrites as required for RBD. This step is complete when a test image written to the datastore lands in the data pool and the performance test results are recorded against your target.
Run a test VM create, migrate and delete cycle
Launch a small test VM from an image in the Ceph image datastore onto the system datastore, then perform a live migration to a second hypervisor, and finally delete the VM and confirm its disks are removed. Repeat with a snapshot attempt in full Ceph mode to confirm behavior. Check the VM console, network and disk I/O from inside the guest during each stage. This step is complete when create, migrate and delete all succeed without orphaned RBD images in the pool, and the results are signed off by the platform owner before production onboarding.
When Ceph mode beats SSH mode for system datastores
Choose Ceph mode for the system datastore whenever you need disk snapshots, which in practice means nearly every production cluster that will run VMs for more than a short test period. In Ceph mode, the VM disks stay as RBD images in the Ceph pool, so the storage layer can take snapshots of them. In SSH mode, OpenNebula exports each disk to the hypervisor's local file system and the datastore does not support disk snapshots at all. That single difference shapes the rest of your design, so settle it before the first VM is created.
The effect on live migration and recovery follows from where the disk lives. With Ceph mode, every hypervisor node is a Ceph client, so a running VM can move to another host without copying its disk, because the disk is already reachable from the destination. With SSH mode, the disk sits on one hypervisor's local file system, and moving the VM means copying that disk across the network, which is slower and depends on the local disk of each host. Backup workflows also change: in Ceph mode you can build backups from storage-level snapshots, while in SSH mode you rely on copies of exported files taken from the host. Confirm the live migration and snapshot behavior for your OpenNebula version in the Ceph datastore documentation before you rely on it.
Treat the mode as a one-way decision for practical purposes. Moving VMs from SSH mode to Ceph mode, or the reverse, is a migration project with downtime planning, disk copies and verification, not a configuration toggle. Before you create any VMs, confirm that your nodes can act as Ceph clients, that the pool and libvirt user are in place, and that your backup tooling can work with the mode you chose. If you are unsure which mode fits your workloads, document the snapshot, migration and recovery requirements first and make the mode decision from that list, then ask your partner or OpenNebula's support channel to validate it against your version.
Choosing a transfer mode by workload
Most general-purpose clusters need snapshots for backup workflows, rollback before patching and quick cloning of templates. Full Ceph mode keeps system disks as RBD images in the cluster, so the datastore can take and manage disk snapshots without copying data to each hypervisor. SSH mode exports each disk to the hypervisor's local file system, and the OpenNebula Ceph datastore documentation states that it does not support disk snapshots. For a general hosting estate, that restriction usually rules SSH mode out.
- Snapshot capability: Full Ceph mode is the mode that keeps disk snapshots available to users and to backup tooling.
- Shared image location: VM disks stay in the Ceph pool, so live migration between hosts does not require moving the disk through the hypervisor file system.
- Client requirements: Every node that runs VMs must be a working Ceph client with access to the monitors and the pool, so network and CephX key setup must be complete before the first VM boots.
- Recovery model: Snapshot-based backup and rollback depend on how your backup product integrates with OpenNebula and Ceph, so confirm that integration rather than assuming it.
- Image format: Confirm that the datastore uses RBD format 2, which the OpenNebula documentation strongly recommends.
Before production, run a snapshot, a restore and a live migration on a test VM, and confirm that the backup process you plan to use works on Ceph-backed disks.
Some workloads, such as databases with heavy small random writes or latency-sensitive batch jobs, may benefit from local disk performance more than from snapshots or shared storage. SSH mode places each disk on the hypervisor's local file system, which can keep I/O on the host. This benefit is real only when the host's local storage is fast and the workload does not need the features that SSH mode removes. The OpenNebula documentation notes that erasure-coded data pools usually reduce I/O performance, so teams that want speed should avoid that option for these VMs.
- Given up: SSH mode gives up disk snapshots and centralized disk placement, so the team must accept those losses for each workload.
- Host-level dependency: A disk lives on one hypervisor, so a host failure affects its VMs until recovery steps restore them elsewhere.
- Capacity planning: Local disks on each host must be sized and monitored separately, because the cluster no longer pools capacity in Ceph.
- Benchmark evidence: Measure the workload on both modes using its own I/O pattern, since general claims about speed do not carry over to every application.
- Data protection: Backups must cover each host's local disks, and restore procedures must be tested for the exported file format.
Before production, benchmark the actual workload on both modes, confirm the host failure procedure, and document which features the workload will no longer have.
Clusters often grow in stages, so some hypervisors have newer CPUs, more memory or different network cards than others. In a mixed cluster, the question is which nodes can act as Ceph clients with the required network paths and libraries, and which nodes need a different approach. OpenNebula's documentation states that nodes must be Ceph clients, so any host that cannot reach the monitors and OSDs over the required network cannot run Ceph-backed VMs. Mixed hardware also means that the same datastore may behave differently on different hosts, which makes testing on each hardware type important.
- Client parity: Check that every host has the same Ceph client version and can authenticate with its CephX key before adding it to the cluster.
- Network paths: Hosts on slower or differently routed links may see different latency to the cluster, which affects VM I/O.
- Placement control: Use cluster and host configuration to keep latency-sensitive VMs on hosts that meet your performance tests.
- Mixed modes: Where some hosts cannot use Ceph and others can, confirm how the datastore and system disks are assigned so VMs do not land on hosts that cannot serve them.
- Upgrade order: Plan hypervisor and Ceph client upgrades so that mixed versions do not stop VM migration between hosts.
Before production, test live migration and VM start on each hardware type, and confirm that placement rules keep VMs on hosts that meet the workload's requirements.
Where storage bridge nodes fit in the design
Storage bridge nodes sit between OpenNebula hypervisors and a Ceph cluster when the hypervisors cannot reach Ceph directly, or when policy keeps them off the storage network. The rule that shapes the design is that every node that runs VMs against Ceph must be a Ceph client. Each one needs the Ceph configuration, a CephX key with access to the datastore pools, and a route to the monitors and OSDs. A bridge node is one way to close a network gap, but it also moves credentials to another host that you must secure and rotate. Confirm in the OpenNebula Ceph datastore documentation for your release which nodes need client packages and keys, because that list determines where credentials live.
Client traffic travels over the Ceph public network to monitors and OSDs. If you separate networks, OSD replication and recovery traffic runs on the cluster network. Map each bridge's path end to end: hypervisor to bridge, then bridge to the Ceph public network. Note whether the bridge also carries the SSH traffic that SSH transfer mode generates. The Ceph hardware recommendations advise bonding network links across two switches, so one switch failure does not cut a bridge off from its datastore. A bridge that serves heavy VM disk I/O competes for the same bandwidth, so size its uplinks for that load and benchmark before you commit, because the same guidance says no two clusters are alike.
Decide early whether bridges are a permanent tier or a temporary step. Each bridge adds a failure point, a patching target and a set of keys to manage, so plan more than one if a single bridge failure must not stall VM operations. Ask the team running the cluster to test a bridge loss during a VM start and during a snapshot, and record how OpenNebula behaves. Then check the full design against the OpenNebula Ceph datastore documentation for the release you run. Driver behavior and supported node roles can change between releases, so treat that check as a gate before go-live, not a one-time task at install.
Mapping OpenNebula datastore attributes to Ceph objects
This table maps the OpenNebula Ceph datastore attributes to the Ceph pools, CephX users, RBD images and hypervisor paths they create or affect. Read each row as a question: which setting decides where a disk lives, who can reach it, and what changes on the hypervisor. Confirm exact attribute names against the OpenNebula release you run before you write a datastore template.
| Attribute | Ceph object or path it affects | What to confirm before you set it |
|---|---|---|
| DS_MAD = ceph and TM_MAD = ceph | Selects the Ceph datastore driver, so images and disks are stored as RBD objects in the Ceph cluster rather than as local files | Set on both image and system datastores; confirm the driver names in the datastore docs for your release |
| DISK_TYPE = RBD | Image datastore entries are created as RBD images in the pool named by the datastore | Image datastores need this type; the disk format should be RBD format 2, as the docs recommend |
| BRIDGE_LIST | Storage bridge hosts that run Ceph client tools and issue image operations on behalf of the front-end | Bridge nodes must be Ceph clients with the keyring and config present; confirm how your release selects them |
| Pool name (image and system datastores) | The RADOS pool that holds RBD images for each datastore, usually one pool per datastore | Create the pool with the replication or erasure profile you planned, and keep image and system data in separate pools |
| CephX user and keyring | The Ceph client identity the nodes use to map RBD images through librbd or the kernel client | Grant only the caps needed on the datastore pool; confirm the key and secret handling your release expects |
| EC_POOL_NAME | A separate erasure-coded data pool for RBD image data, with metadata kept in the replicated pool | Erasure-coded pools save space but usually reduce I/O performance; test your workload before you choose it |
| Hypervisor path in SSH mode | Each disk is exported to a local file on the hypervisor, so no RBD object is mapped on the host during the VM's life | SSH mode does not support disk snapshots; confirm which operations your users need before choosing this mode |
| Full Ceph mode system datastore | Disks are attached to the VM as RBD devices through the hypervisor, so the host needs Ceph client access to the pool | Every hypervisor node must reach the monitors and OSD network; plan the network path and CephX access first |
Securing the CephX user and the hypervisor path
The OpenNebula Ceph datastore gives every hypervisor a path to your storage cluster, so the identity it uses and the way its traffic travels matter as much as the pool layout. The cards below cover the CephX user, the keyring files on each node, encrypted transport, admin separation and patching. Confirm the exact capability syntax in the Ceph documentation before you apply it.
Scope the CephX user to datastore pools
Create a dedicated CephX user for OpenNebula and grant it read and write access only to the image and system datastore pools, plus the namespace or RBD features it needs. Avoid the admin keyring and avoid broad allow * capabilities, since a leaked key then reaches every pool in the cluster. Ask your Ceph administrator to confirm the capability syntax for your Ceph release in the Ceph documentation, and test that the user cannot list or touch unrelated pools.
Lock down keyring file permissions
Each hypervisor node holds a keyring for the OpenNebula user, so that file is a credential. Keep it readable only by the account that runs the OpenNebula transfer and libvirt processes, and avoid copying it into shared configuration or images. Check ownership and mode after every node rebuild, and confirm with your team how the keyring is distributed and rotated when a node is retired.
Enable msgr2 secure mode
Ceph messenger v2 listens on port 3300 and offers a secure mode that encrypts all traffic after authentication with AES-GCM and adds integrity checks. Enable it where your Ceph clients and nodes support it, and confirm that hypervisor clients connect with secure mode rather than falling back to plain transport. Plan for the CPU cost of encryption on busy hypervisors and measure it during testing.
Separate admin and service roles
The people who administer the Ceph cluster should not use the OpenNebula service account, and the OpenNebula service account should not be able to change cluster-wide settings. Keep cluster admin keys in your secrets store under a small group of operators, and give the datastore user only what the datastore needs. Review who holds each key and record changes, because a shared key makes incident response slow.
Patch through active Ceph releases
Run a Ceph release that is still actively maintained so security fixes and periodic backports reach your cluster. Track the end-of-life dates for each release in the Ceph releases page and plan upgrades before support ends. Schedule patching for both the Ceph cluster and the client packages on hypervisor nodes, since a fix on the server does not protect a node running an old client library.
Common Ceph datastore failures and fixes
This table pairs common failures seen when OpenNebula uses Ceph datastores with their likely causes and the first fixes to try. Read each row against the symptom your hypervisor or OpenNebula logs show, then confirm the fix in a test datastore before changing production. Most failures trace back to client packages, CephX capabilities, the chosen transfer mode or the RBD format.
| Failure | Likely cause | Fix to try first |
|---|---|---|
| Hypervisor cannot attach or map RBD disks | Ceph client packages missing or mismatched on the hypervisor node | Install the Ceph client packages matching your cluster release on every node that runs VMs, then confirm the node can reach the cluster with the same configuration file and keyring. |
| Authentication errors when OpenNebula talks to the pool | Wrong CephX keyring, or the libvirt user lacks the capabilities the datastore needs | Recreate the user with capabilities scoped to the image and system pools, copy the keyring to the expected path on each node, and retest with the user name set in the datastore template. |
| Snapshot requests fail on a system datastore | The datastore runs in SSH mode, which exports disks to local files and does not support disk snapshots | Confirm the transfer mode in the system datastore configuration. If snapshots are required, move the system datastore to full Ceph mode and plan the migration of existing VMs. |
| Images or disks behave inconsistently or fail to create | RBD format is not format 2, or an older format was created in a pool used by OpenNebula | Use RBD format 2 as the docs recommend, and check the format of existing images before reuse. Confirm with your OpenNebula documentation version how to convert or recreate affected images. |
| Erasure-coded datastore is slower than expected | EC_POOL_NAME trades I/O performance for space efficiency, so write and small-I/O latency usually rise | Compare against a replicated pool using the same hardware and workload. If the trade-off is unacceptable, use replicated pools for latency-sensitive VMs and keep erasure coding for capacity-oriented data. |
| Hypervisors cannot reach the cluster on port 3300 | Messenger v2 traffic blocked by a firewall, or monitors listed by address the node cannot route to | Open the monitor port 3300 for messenger v2 (and the legacy port 6789 if your configuration uses it) between hypervisors and monitors, and verify monitor addresses in the client configuration. |
| Datastore works on some nodes but not others | Inconsistent configuration files, keyrings or package versions across hypervisor nodes | Compare the Ceph client version, configuration file and keyring path on each node, and standardize them with a single deployment process before adding more hosts. |
Questions buyers ask before configuring Ceph for OpenNebula
How much effort does a Ceph datastore integration for OpenNebula take?
Effort depends mostly on the Ceph cluster and the OpenNebula layout you already have, not on the OpenNebula side alone. The main drivers are the number of hypervisor nodes that must act as Ceph clients, the number of pools you need (image, system and any erasure-coded data pool), how many storage bridge nodes are involved, and whether the Ceph cluster is new or already in production. A small cluster with a few hypervisors and one image datastore is a bounded task. Each additional cluster, datastore or failure domain adds configuration, testing and documentation. Ask any provider to break the estimate down by these items so you can see what each one adds.
Can our own team set up Ceph datastores for OpenNebula internally?
Often yes, if you already run Ceph and OpenNebula in production and have people who can manage CephX users, RBD pools and libvirt on the hypervisors. The OpenNebula Ceph datastore documentation sets out the required steps, including that nodes must be Ceph clients and that RBD format 2 is strongly recommended. The gaps usually appear in testing: verifying snapshot behavior, failure handling and recovery, and checking that the chosen transfer mode matches your workloads. Be honest about who on your team owns each of these. If no one has run both platforms before, a partner can cover the design and build while your staff learn to operate the result.
What do we need to provide during a Ceph and OpenNebula engagement?
Plan for access and time from your own side before work starts. The usual requirements are administrative access to the Ceph cluster to create pools and CephX users, access to the OpenNebula front-end and the hypervisor nodes that will run the datastore, and approval for any network changes, such as routing the Ceph public network to hypervisors or storage bridge nodes. You will also need scheduled test windows for changes that affect running virtual machines, and a named person who can approve cutover. Confirm each of these in writing during scoping so that delays do not surface in the middle of the build.
How long does a Ceph datastore integration for OpenNebula take?
Duration follows scope. A single datastore on an existing, healthy Ceph cluster with a small number of hypervisors is much shorter than a multi-cluster design with erasure-coded data pools, several storage bridge nodes and migration of existing virtual machines. Ask for a timeline tied to named deliverables, with the dependencies you cannot control, such as hardware delivery, change approval windows and the Ceph cluster's current health, listed separately. We do not publish durations, so the written scope is the basis for any date.
Can we switch from SSH mode to Ceph mode for system datastores later?
Switching is possible in principle, but it is not a simple setting change, and you should plan it as a migration. According to the OpenNebula Ceph datastore documentation, system datastores can run in full Ceph mode or SSH mode, and SSH mode exports each disk to the hypervisor's local file system and does not support disk snapshots. Moving running or stopped virtual machines from SSH mode to Ceph mode therefore needs a tested procedure, a rollback plan and a decision about existing snapshots. Confirm the exact steps for your OpenNebula version with the vendor documentation before you commit to SSH mode for production workloads.
What should a fixed-scope quote for this integration include?
A fixed-scope quote should name the work in terms you can check. Expect to see the Ceph version and cluster state assumed at the start, the pools and CephX users to be created, the datastore modes chosen for image and system datastores with the reason for each, the storage bridge node design if one is used, and whether erasure-coded data pools are included with their performance trade-offs stated. It should also list the verification steps, such as snapshot and live migration tests, failure tests, handover documentation and any post-go-live support. Finally, it should state what is excluded, the assumptions you must meet and the acceptance criteria. Ask for a written scope before work starts, since DeployOpen agrees scope, deliverables and timelines in writing before any engagement begins.
Do erasure-coded data pools make sense for OpenNebula Ceph datastores?
They can, when capacity matters more than I/O performance. The OpenNebula Ceph datastore documentation notes that EC_POOL_NAME enables erasure-coded data pools, which save space but usually reduce I/O performance. Virtual machine disks are often latency and random-write sensitive, so test the workload before choosing this option for production images. Ask the provider to benchmark representative I/O on both replicated and erasure-coded pools, and to document which datastores use which layout. The Ceph hardware recommendations also advise benchmarking before buying, because no two clusters are alike.
How DeployOpen works on this
DeployOpen plans, implements, tests, documents and supports self-hosted open-source platforms inside your own infrastructure, including the Ceph and OpenNebula components behind this integration. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we scope
- Review your OpenNebula front-end, hypervisor nodes and network layout before proposing any datastore design.
- Confirm the Ceph cluster, pools, CephX users and whether image and system datastores run in full Ceph or SSH mode.
- Record the erasure-coded pool decision and its I/O trade-off in the written scope before any build starts.
- Agree in writing which tests, documents and handover items are included, and what your team must provide.
How we build
- Create the RBD pools, libvirt client keys and datastore definitions according to the agreed design.
- Configure storage bridge nodes and confirm every hypervisor node is a working Ceph client.
- Test VM creation, live migration, disk attach and detach, and snapshot behavior against the chosen transfer mode.
- Validate failure scenarios such as a node loss or a Ceph health warning before the datastore goes live.
How we hand over
- Deliver a written record of pool names, client capabilities, datastore settings and network paths.
- Document the SSH mode limits, including the absence of disk snapshots, so operators plan around them.
- Walk your operations team through routine checks, capacity monitoring and the upgrade path for both platforms.
- Hand over runbooks for adding hypervisor nodes and rotating CephX keys in your environment.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after the initial handover.
- Plan OpenNebula and Ceph upgrades together, checking compatibility against the release documentation before each change.
- Re-test the datastore after major changes to hypervisors, networking or Ceph releases.
- Confirm support coverage and response expectations in the written agreement, since these vary by engagement.
