Skip to content
English
  • There are no suggestions because the search field is empty.

Deployment: Comprehensive Device Sizing and Virtual Machine Guidelines

Table of Contents

  • Overview
  • Supported Hypervisors
  • Global Minimum VM Requirements
  • Appliance-Specific Minimum Requirements
    • Critical System Gateway (CSG)
    • Xona Connection Manager (XCM)
  • Performance Scaling & Resource Allocations
    • Base Protocols (SSH/VNC/RDP) vs. Web Connections
    • Dynamic Scaling Recommendations
  • Storage Management & Scaling
    • Initial Provisioning (100 GB)
    • Expanding Storage Space
    • Storage Constraints
  • Considerations and Known Issues
  • Related Articles

Overview

Proper sizing of your Xona Critical System Gateway (CSG) and Xona Connection Manager (XCM) ensures stable performance, reliable session recording, and secure protocol isolation. This comprehensive guide outlines the baseline hardware and Virtual Machine (VM) specifications required to deploy the appliance successfully using the general-purpose, hypervisor-agnostic ISO image, as well as dynamic scaling rules for high-concurrency environments.

Supported Hypervisors

Xona appliances can be deployed as virtual machines on popular hypervisors. Xona tests each release's ISO image specifically on the following platforms:

  • VMware ESXi 8.x
  • QEMU with KVM on AlmaLinux 9.x

Note: Other hypervisors are expected to work provided they align with the virtual hardware requirements below. Nutanix deployments are supported but must use legacy BIOS; UEFI is not supported on the Nutanix platform.

Global Minimum VM Requirements

All Xona appliances deployed as virtual machines require the following baseline virtual hardware configuration:

  • CPU Architecture: x86 64-bit CPU architecture (Note: ARM architecture is strictly not supported, with or without emulation).
  • Network Adapter: Intel-compatible virtual network interface.
  • Storage: 100 GB Virtual Disk.

Appliance-Specific Minimum Requirements

Critical System Gateway (CSG)

  • vCPU: 2 or more vCPUs (dependent on underlying hypervisor hardware).
  • RAM: 4 GB minimum (8 GB recommended). See the Performance Scaling section below if utilizing Web Connections.
  • Network Interfaces: Up to 2 virtual Network Interface Cards (vNICs).
  • Required Ports:
    • TCP port 443 open to all client networks (and HA replica, if applicable).
    • TCP port 22 open for administrators (optional but recommended to be restricted to trusted IP spaces).

Xona Connection Manager (XCM)

  • vCPU: 8 or more vCPUs.
  • RAM: 4 GB minimum (8 GB or more recommended).
  • Network Interfaces: 1 virtual network interface (up to 2 are supported).
  • Required Ports:
    • UDP port 39251 open to all connected CSGs (and respective HA replicas, if applicable).
    • TCP port 443 open to all client networks (and HA replica, if applicable).
    • TCP port 22 open for administrators (optional).

To better understand all required firewall rules for Xona XCMs and CSGs, please refer to the following KB article: What are the network requirements?

 Performance Scaling & Resource Allocations

While a base CSG can operate on 2 vCPUs and 4 GB of RAM, Xona anticipates that customers will need to change vCPU and RAM allocations over time to fit their specific operational technology (OT) use cases. Resource consumption varies heavily depending on the type of connection profiles your users are launching.

Base Protocols (SSH/VNC/RDP) vs. Web Connections

  • Base Protocols (SSH, VNC, RDP): These protocols are highly efficient. The CSG acts as an isolated broker, translating the native endpoint protocol into a secure HTML5 canvas stream. A CSG configured with the recommended 8 GB of RAM can comfortably handle standard concurrent loads for these protocols.
  • Web Connections (HTTP/HTTPS): Proxying web connections through the CSG requires significantly more overhead. Because modern web applications are complex, rendering an isolated browser session securely through the Xona interface demands substantially more RAM and CPU cycles per concurrent user compared to a standard terminal or desktop session.

Dynamic Scaling Recommendations

Xona appliances fully support increasing appliance RAM and CPU counts after initial deployment.

  • If your primary use case involves users accessing OT web interfaces concurrently, the baseline 8 GB of RAM must be increased.
  • Monitor your system via the Xona Web UI (Settings > Appliance > Status). If CPU usage consistently peaks or memory swapping occurs during high-concurrency Web Connection shifts, safely shut down the VM, increase the vCPU and RAM allocation at the hypervisor level, and reboot the appliance.

Storage Management & Scaling

Xona appliances utilize localized virtual disks to maintain audit trails. This storage is split between two primary functions: Session Recordings (Video Buckets) and File Transfers (File Buckets) based on a percentage slider in the Web UI. The combination of video and file buckets must equal 100% of your allocated storage capacity.

Initial Provisioning (100 GB)

By default, all Xona VM deployments require a 100 GB virtual disk to properly install the base operating system, container architecture, and initial bucket partitions.

Expanding Storage Space

If your retention policies require longer audit histories, or your users are transferring massive payload files via the File Buckets, you may be able to increase the storage capacity of the appliance.

If your Xona VM was provisioned on v5.3.3 or newer, then the following directions apply:

  1. Ensure the Xona VM is safely powered down.
  2. Within your hypervisor, edit the hardware settings of the VM.
  3. Increase the size of the primary virtual disk (e.g., from 100 GB to 500 GB).
  4. Power the VM back on.
  5. During the boot sequence, the Xona appliance will automatically detect the expanded disk and seamlessly allocate the added disk space to expand your video and file bucket storage.

If your Xona VM was provisioned on v5.3.2 or older, then the VM storage expansion option is not available. Instead of expanding the storage of the existing VM, the recommended path forward is to migrate to a newer Xona VM. Please contact support@xonasystems.com if you would like assistance or have questions about how to achieve this.

Storage Constraints

When managing Xona storage, you must strictly adhere to the following architectural limitations:

  • No Secondary Disks: Adding additional or secondary virtual disks to the VM is not supported. All storage expansion must occur by extending the primary drive.
  • No Shrinking: Decreasing the disk size after it has been expanded is not supported and will corrupt the appliance file system. Ensure your storage expansions are calculated carefully before applying them at the hypervisor level.

Considerations and Known Issues

  • Cloning Prohibited: Each VM deployed using the ISO image is individually licensed. Using VM cloning to bypassing the End User License Agreement (EULA) license restrictions is strictly prohibited and not supported.
  • Network Architecture Lock: Changing the number of VM network interfaces at the hypervisor level requires a system reset thereafter. It is highly recommended to confirm your network architecture (1 vNIC vs. 2 vNICs) before deploying.
  • High Availability: Stratus everRun deployments running in HA or FT protection modes are not supported (this refers to the everRun option and is unrelated to standard Xona appliance replication).
  • Encryption: Virtual TPM integration (for native disk encryption key storage) is currently not supported. If a virtual TPM is added to the Xona VM, it will not be utilized by Xona. Customers requiring storage encryption are encouraged to use hypervisor-specific features.