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
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
The XSDS module is organized into four tabs, each covering a distinct aspect of storage cluster management.
Bootstrap Configuration
Storage Tiers
Config File
Logs
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.
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., 10.0.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.
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.
The right side of the tab displays reference information:
Storage Tiering
Explains what storage tiering does --- grouping disks by media type and creating separate pools so tenants can select performance tiers when creating volumes.
What Gets Configured
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.
Requirements
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.
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.
After configuring XSDS, verify that the storage cluster is operational:
Verify Bootstrap Completion
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.
Verify Storage Tiers
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.
Review Configuration
Open the Config File tab and verify that the cluster configuration reflects your network CIDRs, replication settings, and container image versions.
Test Volume Creation
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.
