> ## Documentation Index
> Fetch the complete documentation index at: https://docs.xloud.tech/llms.txt
> Use this file to discover all available pages before exploring further.
# XSDS Storage
> Deploy and manage distributed storage for block, object, and file services
XSDS manages the distributed storage cluster that provides block storage (virtual machine disks), object storage (S3-compatible), and file storage (shared filesystems). Data is replicated across multiple nodes for reliability and high availability. This tool handles bootstrapping the initial storage cluster, configuring storage tiers by media type, editing the cluster configuration file, and viewing deployment logs.
**Prerequisites**
* Hosts configured with **XSDS-Bootstrap** and **XSDS** roles in [Hosts](/deployment/hosts)
* Dedicated storage disks available on at least one node (separate from the root filesystem)
* Network connectivity between all storage nodes on the storage network plane
***
## XSDS Tabs
The XSDS module is organized into four tabs, each covering a distinct aspect of storage cluster management.
The Bootstrap Configuration tab handles the initial cluster creation on the first designated node. This is a one-time operation that creates the monitor daemon, manager daemon, and cluster identity. All subsequent nodes join this cluster.
***
### Container Image
| Field | Description |
| ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------ |
| **XSDS Container Image** | Select the storage daemon container image version from the dropdown. The available images are loaded from the local Docker registry. |
***
### Bootstrap Settings
| Setting | Description |
| ------------------------ | ----------------------------------------------------------------------- |
| **Monitor IP Address** | IP address of the first monitor node (auto-detected from inventory) |
| **Bootstrap Hostname** | Hostname of the initial node (auto-detected from inventory) |
| **Public Network CIDR** | CIDR for client-to-storage communication (e.g., `10.0.0.0/24`) |
| **Cluster Network CIDR** | CIDR for storage-to-storage replication traffic (e.g., `172.16.1.0/24`) |
Keeping replication traffic on a separate cluster network prevents it from competing with client I/O. This separation is critical for production performance --- without it, heavy replication during recovery events can saturate the client-facing network and degrade VM disk performance.
***
### Custom Bootstrap Attributes
Additional flags that modify bootstrap behavior for non-standard environments. Expand this section to configure advanced options:
| Flag | Purpose |
| ------------------------ | ------------------------------------------------------------------------------------ |
| `--allow-overwrite` | Permit re-bootstrapping on a node that was previously initialized |
| `--skip-pull` | Skip container image download if the image is already present locally |
| `--skip-firewalld` | Do not attempt to configure firewall rules (use when firewall is managed externally) |
| `--single-host-defaults` | Apply defaults suitable for single-node development deployments |
***
### Bootstrap Command
The tab displays a preview of the full bootstrap command that will be executed based on your configuration. Review the command before proceeding.
Click **Run Bootstrap Command** to execute the bootstrap operation. Progress streams live to the Logs tab.
Bootstrap is a destructive operation on the target node. Running it on a node that already has a storage cluster without `--allow-overwrite` will fail. Running it with `--allow-overwrite` will destroy the existing cluster data on that node.
The Storage Tiers tab manages storage tiers by grouping disks by media type (NVMe, SSD, HDD) and creating separate CRUSH rules, pools, and volume types for each tier. This enables offering multiple volume types within the same cluster.
***
### Actions
| Button | Description |
| ----------------------- | -------------------------------------------------------------------------------------------------------------------------------- |
| **Detect Tiers** | Query the storage cluster for all available device classes. The system inspects every OSD and reports its underlying media type. |
| **Apply Configuration** | Creates the CRUSH rules, storage pools, and registers corresponding volume types based on detected tiers. |
Click **Detect Tiers** to scan the cluster. After reviewing the results, click **Apply Configuration** to create the tier infrastructure.
***
### Information Cards
The right side of the tab displays reference information:
Explains what storage tiering does --- grouping disks by media type and creating separate pools so tenants can select performance tiers when creating volumes.
Details the resources created when applying tiers: CRUSH rules pinned to device classes, dedicated storage pools per tier, volume types registered in the block storage service, and Prometheus metrics for tier monitoring.
Lists prerequisites for tier configuration: a running storage cluster with at least one OSD, and mixed media types (NVMe, SSD, HDD) for multiple tiers.
Without tiers, all data lands on whatever disks are available. With tiers, you can offer **Fast SSD Storage** and **Standard HDD Storage** as distinct volume types --- giving tenants control over performance and cost trade-offs.
The Config File tab provides a direct editor for the initial storage cluster configuration file (`ceph.conf`). Use this to review and modify low-level cluster settings before or after bootstrap.
***
### Configuration Editor
| Element | Description |
| ------------------------------ | ------------------------------------------------------------------------------ |
| **Initial Ceph Configuration** | Header indicating this is the base cluster configuration |
| **Reload** | Button to reload the configuration from the server, discarding unsaved changes |
| **Save Configuration** | Button to write the edited configuration back to the server |
| **Configuration Content** | Text area displaying the full `ceph.conf` file |
The configuration content is organized into standard sections:
| Section | Contents |
| ---------------- | -------------------------------------------------------------------------- |
| `[global]` | Cluster identity, FSID, authentication mode, placement group settings |
| Networking | Public and cluster network CIDRs, bind addresses |
| Container Images | Storage daemon container image references |
| Security | Authentication settings, keyring paths |
| Pool Defaults | Default replication size, minimum replication, placement group auto-tuning |
Modifying the cluster configuration directly can impact cluster stability. Only edit settings you understand. Incorrect values for replication size, network CIDRs, or authentication can make the cluster inaccessible.
Use the Reload button before making changes to ensure you are editing the latest version of the configuration. After saving, verify the cluster remains healthy by checking the cluster status.
The Logs tab displays deployment and operation logs for all XSDS activities --- bootstrap commands, tier detection, configuration changes, and error output.
| Column | Description |
| ------------- | ----------------------------------------------------------------------------------------- |
| **Timestamp** | Date and time of each log entry |
| **Operation** | The XSDS operation that generated the log (bootstrap, tier detection, configuration save) |
| **Output** | Command output, status messages, and any error details |
Review the Logs tab after every XSDS operation to confirm success. Bootstrap operations stream output in real time. If an operation fails, the error details displayed here are the primary diagnostic resource.
***
## Validation
After configuring XSDS, verify that the storage cluster is operational:
Check the Logs tab for a successful bootstrap message. The bootstrap command should complete without errors, confirming that the monitor and manager daemons are running.
Switch to the Storage Tiers tab and click **Detect Tiers**. Confirm that the detected device classes match your physical hardware inventory. If tiers have been applied, verify that the corresponding volume types are registered.
Open the Config File tab and verify that the cluster configuration reflects your network CIDRs, replication settings, and container image versions.
Create a test volume using each configured volume type to confirm that data placement follows the tier rules. Verify the volume is accessible and writable from a compute instance.
Storage cluster bootstrapped, tiers configured, and test volumes created successfully.
***
## Next Steps
Manage volume types and storage tier policies for tenants
Visualize your entire infrastructure topology including storage nodes