> ## 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.
# Configuration
> Configure networking, storage, monitoring, and security settings for your cloud deployment
## Overview
Configuration is the main settings interface for your entire cloud. All settings are saved to `globals.yml` --- the master deployment configuration file that controls every aspect of your environment. Instead of editing YAML manually, XDeploy provides forms, dropdowns, toggles, and validation across eight configuration tabs.
**Prerequisites**
* Bootstrap completed on the deployment server
* Hosts configured with verified SSH access
* Network interface names identified on all target servers
* Virtual IP (VIP) addresses planned for your management subnet
***
## Configuration Tabs
Log in to **XDeploy** (`https://xdeploy.`) on the deployment node using administrative access.
Navigate to **Configuration** in the left sidebar. The configuration interface is organized into eight tabs, each handling a distinct area of your deployment settings.
The primary settings tab covering networking, domains, and TLS configuration. These settings form the foundation of your entire deployment.
***
### Network Configuration
| Field | Required | Description |
| ------------------------------------ | -------- | --------------------------------------------------------------------------------------------------------------------- |
| **API/Management Network Interface** | Yes | Select the NIC used for management traffic. Auto-fills the Internal VIP field based on the selected interface subnet. |
| **Internal VIP Address** | Yes | Virtual IP for internal API calls. Floats between controllers via HAProxy for high availability. |
| **External VIP Address** | No | Public-facing VIP for external access and the Xloud Dashboard. Required only if external access is needed. |
The Internal VIP is the single most important setting in your deployment. If it is wrong, nothing works. Ensure it is an **unused** IP address on the management subnet that does not conflict with any existing host.
***
### Domain Configuration
| Field | Description |
| ----------------------- | ----------------------------------------------------------------------------------------------------- |
| **Enable Domain Setup** | Toggle to configure FQDNs instead of raw IP addresses for service endpoints |
| **Internal FQDN** | Hostname for internal API endpoints (e.g., `xavs-int.example.com`). Must resolve to the Internal VIP. |
| **External FQDN** | Hostname for external access (e.g., `xavs.example.com`). Must resolve to the External VIP. |
***
### TLS/SSL Configuration
Visible when Domain Setup is enabled. Configure certificate-based encryption for API endpoints.
| Field | Description |
| -------------------- | ----------------------------------------------------------------------------------------------------- |
| **Internal API TLS** | Toggle to enable TLS for internal service communication. Upload the certificate and private key. |
| **External API TLS** | Toggle to enable TLS for the public-facing Dashboard and API. Upload the certificate and private key. |
Certificates are saved to `/etc/xavs/certificates/` on the deployment node and distributed to all controllers during deployment.
For production deployments, always enable TLS on external endpoints. Internal TLS is recommended when the management network is shared or untrusted.
Configures the Xloud Networking service --- interfaces, provider networks, and optional networking features.
***
### External Interface
| Field | Description |
| ------------------------------ | ------------------------------------------------------------------------------------ |
| **External Interface Mode** | **Single** (one NIC for all external traffic) or **Multiple** (per-host NIC mapping) |
| **Neutron External Interface** | The NIC used for provider networks and external VM connectivity |
The selected external interface **loses its current IP address** after deployment. It is enslaved to a network bridge for provider traffic. Ensure this NIC name exists on **all hosts** that require external connectivity.
***
### Feature Toggles
| Feature | Default | Purpose |
| --------------------- | ------- | ------------------------------------------------------------------ |
| **Provider Networks** | ON | Direct VM connection to physical networks, floating IP support |
| **VPNaaS** | OFF | Site-to-site VPN tunnels between tenant networks |
| **QoS** | OFF | Bandwidth limits, DSCP marking, minimum rate guarantees |
| **Trunk** | OFF | 802.1Q VLAN trunking on VM ports |
| **Agent HA** | OFF | High availability for L3 and DHCP agents across multiple nodes |
| **SR-IOV** | OFF | Hardware-accelerated networking via Single Root I/O Virtualization |
Feature toggles marked OFF are premium or specialized capabilities. Enable them based on your workload requirements. Each can be activated at any time via reconfiguration.
Configures Xloud Block Storage --- the persistent volume service for VM disks.
***
### Service Toggles
| Field | Description |
| ------------------------------- | ---------------------------------------------------------------------------------- |
| **Enable Block Storage** | Master switch for the volume service. Disabling removes all storage functionality. |
| **Enable Block Storage Backup** | Enables volume backup and restore capabilities |
| **Storage Backend Type** | **Single** (one backend) or **Multiple** (tiered storage with multiple backends) |
***
### Backend Options
| Backend | Description | Best For |
| ---------------- | ----------------------------------------------- | ------------------------------------------- |
| **LVM** | Local disk volumes using Logical Volume Manager | Single-node deployments, testing |
| **Ceph RBD** | Distributed replicated block storage | Production, high availability (recommended) |
| **NFS** | Network file share as a volume backend | NAS appliance integration |
| **iSCSI** | Block storage over the network | Enterprise SAN arrays |
| **VMware VMDK** | VMware datastore volumes | VMware-integrated environments |
| **Pure Storage** | FlashArray via iSCSI, Fibre Channel, or NVMe | High-performance enterprise storage |
For production multi-node deployments, Xloud recommends **Ceph RBD**. It provides data replication across nodes, eliminating single points of failure for VM disks.
Configures the Xloud Load Balancer service for distributing network traffic across backend instances.
***
### Enable Load Balancer
| Field | Description |
| ------------------------ | ----------------------------------------------------------------------- |
| **Enable Load Balancer** | Master switch to enable the load balancer service across the deployment |
Enabling the load balancer service deploys additional infrastructure components including controller agents and amphora VMs. Ensure sufficient compute capacity before enabling.
***
### Controller Interface
| Field | Description |
| ----------------------------------- | ------------------------------------------------------------------------------------------------------------------- |
| **LB Management Network Interface** | Select the network interface used for load balancer management traffic between the controller and amphora instances |
***
### Amphora Network Configuration
Configure the dedicated management network used for communication between the load balancer controller and amphora instances.
| Field | Description |
| -------------------- | --------------------------------------------------------------- |
| **Network Name** | Name for the load balancer management network |
| **Network CIDR** | Subnet range for the management network (e.g., `172.24.0.0/24`) |
| **Physical Network** | The underlying physical network for the management VLAN |
| **VLAN ID** | VLAN tag for isolating load balancer management traffic |
| **IP Pool Start** | First IP address in the allocation pool for amphora instances |
| **IP Pool End** | Last IP address in the allocation pool for amphora instances |
***
### Amphora Flavor Configuration
Define the compute resources allocated to each amphora instance. Amphora instances are lightweight VMs that perform the actual load balancing.
| Field | Default | Description |
| --------- | ------- | ------------------------------------------- |
| **vCPUs** | 2 | Number of virtual CPUs per amphora instance |
| **RAM** | 4096 MB | Memory allocation per amphora instance |
| **Disk** | 20 GB | Root disk size per amphora instance |
***
### Topology
| Option | Description |
| ------------------- | -------------------------------------------------------------------------------------------- |
| **SINGLE** | One amphora instance per load balancer. Suitable for non-critical workloads. |
| **ACTIVE\_STANDBY** | Two amphora instances per load balancer with automatic failover. Recommended for production. |
***
### Certificate Configuration
Configure the certificate authority parameters used for secure communication between the load balancer controller and amphora instances.
| Field | Description |
| ---------------- | ----------------------------------------------------------- |
| **Country** | Two-letter country code for the CA certificate (e.g., `US`) |
| **State** | State or province for the CA certificate |
| **Organization** | Organization name for the CA certificate |
| **Org Unit** | Organizational unit for the CA certificate |
The ACTIVE\_STANDBY topology provides high availability for load balancers at the cost of double the amphora resources. For production deployments, always use ACTIVE\_STANDBY.
Configure observability, logging, and security monitoring for your cloud environment.
| Feature | Default | Description |
| -------------------------- | ------- | ------------------------------------------------------------------------------------------------------------------------------- |
| **Enable Prometheus** | OFF | Metrics collection from all cloud services and infrastructure |
| **Enable Grafana** | OFF | Visual dashboards for metrics visualization and analysis |
| **Enable Central Logging** | OFF | Aggregated log search and analysis across all nodes |
| **Enable Security Suite** | OFF | Integrated SIEM, vulnerability scanning, OS hardening, and security posture dashboard (visible when Central Logging is enabled) |
***
### CIS Compliance Level
Visible when Security Suite is enabled. Select the compliance benchmark level:
| Level | Description |
| ----------- | ------------------------------------------------------------------------------ |
| **Level 1** | Essential security controls with minimal performance impact |
| **Level 2** | Extended controls for high-security environments |
| **STIG** | Defense-grade hardening based on DISA Security Technical Implementation Guides |
| **All** | Apply all available compliance benchmarks |
***
### Alert Configuration
Visible when Prometheus is enabled. Configure alert delivery channels.
| Field | Description |
| --------------- | ---------------------------------------------- |
| **SMTP Server** | Mail server for email alert delivery |
| **Alert Email** | Recipient address for alert notifications |
| **Webhook URL** | HTTP endpoint for webhook-based alert delivery |
Each channel includes a **Test** button to verify connectivity before deployment.
Configure at least one alert channel before deploying to production. Without alerts, critical infrastructure issues may go undetected.
Enable or disable premium and specialized services. Each toggle activates the corresponding service and its dependencies during deployment.
| Feature | Default | Description |
| --------------------------------------- | ------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Enable KMS** | OFF | When enabled, the Xloud Key Management service (Barbican) is deployed for secret storage, encryption keys, and certificate management |
| **Enable Host HA** | OFF | Enable high availability for hosts. Automatically detects and recovers from compute node failures by evacuating affected instances to healthy nodes. |
| **Enable Dynamic Cluster Optimization** | OFF | Enable the dynamic cluster optimization service for automated workload balancing, resource consolidation, and thermal management across the cluster |
| **Enable DB Backup Utility** | OFF | Enable the database backup utility for scheduled and on-demand backups of cloud service databases |
| **Enable ProxySQL** | OFF | Enable ProxySQL for database load balancing and query routing across multiple database replicas |
| **Enable Disk Encryption** | OFF | Enable disk encryption using key management for volume-level encryption at rest. Requires KMS to be enabled first. |
| **Enable Insecure Registry** | OFF | Enable custom Docker registry configuration (`docker-registry:4000`) for internal container image distribution |
**Enable Disk Encryption** depends on **Enable KMS**. If KMS is not enabled, the disk encryption toggle has no effect. Enable KMS first, then enable disk encryption.
These are premium or specialized capabilities that are disabled by default. Enable them based on your workload requirements. Each feature can be activated at any time via reconfiguration and redeployment.
A raw YAML editor for deployment settings not covered by the other tabs. Content entered here is appended directly to `globals.yml` during deployment.
| Field | Description |
| ------------------------ | ----------------------------------------------------------------- |
| **Custom Configuration** | Raw YAML key-value pairs appended to the deployment configuration |
| **Documentation** | Free-text area for comments and notes about custom settings |
Use Custom Configuration as an escape hatch. There are hundreds of deployment variables available in the underlying automation --- the other tabs cover the most common ones. Consult the [xavs-ansible variable reference](https://docs.xloud.tech) for the full list.
```yaml title="Example custom configuration" theme={null}
nova_compute_virt_type: "kvm"
neutron_plugin_agent: "openvswitch"
haproxy_max_connections: 40000
```
View the history of configuration changes --- what was saved, when it was saved, and what changed between versions.
XDeploy automatically backs up the last **5 versions** of your configuration. If a configuration change causes issues, you can review previous versions to identify what changed.
| Column | Description |
| ------------- | ----------------------------------------- |
| **Timestamp** | Date and time the configuration was saved |
| **Changes** | Summary of fields that were modified |
| **Version** | Sequential version number for tracking |
***
## Next Steps
Pull or extract container images required for deploying cloud services
Deploy, upgrade, reconfigure, and manage cloud services across your cluster