XCP-ng Documentation

website·Indexed 36 days ago

https://docs.xcp-ng.org/

Documentation for the XCP-ng hypervisor, covering VM creation, snapshots, and migration. Includes release information for versions 8.1, 8.2, and 8.3 LTS, storage repository (SR) management, iSCSI multipathing, and troubleshooting guides for XAPI and High Availability (HA). Provides technical details on UEFI Secure Boot, Windows VM configuration with vTPM, and a CLI reference for appliance and audit commands.

Tokens
105.8K
Snippets
519
Records
855
Agent score
69%

What's inside XCP-ng

  1. Overview of Xen Orchestra backup capabilities

    Xen Orchestra (XO) is the officially supported, agentless, open-source backup solution for XCP-ng. It integrates directly with the platform to provide various backup and replication strategies, including automated rolling snapshots, full and incremental backups, and mirror backups. It supports NFS, SMB, and S3 compatible repositories, and offers features such as encryption, compression, file-level restore, and rate limiting. For increased speed, it supports NBD-enabled networks.
  2. Overview of QCOW2 support in XCP-ng

    QCOW2 is a virtual disk image format from the QEMU project supported by XCP-ng. Its primary advantage over the historical VHD format is the ability to support disks larger than 2 TiB, with current support up to 16,381 GiB. QCOW2 and VHD can co-exist within the same Storage Repository (SR). By default, XCP-ng uses VHD, but will automatically create a QCOW2 disk if a VDI larger than 2040 GiB is requested on a compatible SR.
  3. Overview of the XCP-ng Koji build system

    XCP-ng uses Koji (derived from the Fedora project) as its automated build system to transform source files and spec files into installable RPMs. Koji handles the creation of buildroots, installation of build dependencies, and the RPM build process. It provides build history, logs, artifacts, a public web interface, a Python-based CLI client, and XML-RPC APIs for scripting. It can also be extended for GPG signing and the creation of RPM repositories.
  4. Overview of XCP-ng XAPI Architecture

    XCP-ng is managed via an API called XAPI. Clients such as Xen Orchestra (XO) or the xe CLI interact with XAPI. XAPI uses an XML database located at /var/lib/xcp/state.db to store all metadata and settings for pools, hosts, and VMs. For application development, it is strongly recommended to build on top of the Xen Orchestra (XO) API rather than XAPI directly to avoid handling Xen-specific logic.
  5. Overview of XCP-ng Load Balancing Plans

    XCP-ng load balancing (managed via Xen Orchestra) automatically distributes virtual machine (VM) workloads across physical hosts to optimize resource usage without service interruption. This is achieved through 'plans' that can operate across a whole XCP-ng infrastructure, including remote datacenters, leveraging live storage motion.
  6. Overview of the XCP-ng Virtualization Platform

    XCP-ng is an open-source, high-performance enterprise virtualization platform based on the Xen Hypervisor. It is designed to run on bare-metal machines as a turnkey appliance. It supports management via a central administration console, API, and CLI, and is compatible with infrastructure-as-code tools like Packer, Terraform, and Ansible.
  7. Overview of Xen Orchestra (XO) for XCP-ng

    Xen Orchestra (XO) is the officially supported central management console for XCP-ng, developed by Vates. It runs as a 24/7 daemon, enabling advanced features beyond basic client functionality, including VM load balancing, SDN control, backup/delta backup, disaster recovery, continuous replication, and ACLs.
  8. Monitor XCP-ng infrastructure with Xen Orchestra

    Xen Orchestra provides a centralized management interface for monitoring XCP-ng. Key capabilities include:

    • Dashboards and Stats: Visualizations for CPU, RAM, network, and disk I/O for pools, hosts, VMs, and Storage Repositories (SR), including health indicators for orphaned VDIs and missing patches.
    • Performance Alerts: The perf-alert plugin sends email notifications when CPU, memory, or SR usage exceeds defined thresholds.
    • Backup Reports: Detailed success/failure reports for backup jobs via email or messaging plugins.
    • Audit Trail: Logs of all administrative actions performed on the infrastructure.
  9. Understand Koji build tags in XCP-ng

    XCP-ng uses Koji tags to provide metadata about the origin of a build. These tags are for informational purposes and do not affect the Koji workflow:

    • built-by-xcp: Built by the XCP-ng build system.
    • built-by-xs: Built by Citrix's internal system (legacy).
    • built-by-centos: Imported unmodified from CentOS.
    • built-by-epel: Imported unmodified from EPEL.
    • centos-{VERSION}: Specifies the CentOS version (e.g., centos-7.5).
    • epel-{MAJOR_VERSION}-{DATE}: Specifies the EPEL version and import date (e.g., epel-7-2019-01-30).
  10. Understand XCP-ng Host API Architecture

    XCP-ng clients communicate with the pool master via the Xen API (XAPI). A single connection to the pool master is sufficient to manage multiple hosts in a pool.

    Clients are categorized as:

    • Stateless: Run only during active use; suitable for basic management tasks.
    • Stateful: Run as a daemon (often in a dedicated VM); required for advanced features. Xen Orchestra is the primary stateful client.
  11. Understand XCP-ng kernel module types

    XCP-ng categorizes kernel modules into three main types based on their support level and purpose:

    • Supported Modules: Included in the base installation (either built into the kernel RPM or provided as separate RPMs like broadcom-bnxt-en). These are pulled as dependencies of the vendor-drivers RPM and receive the most testing.
    • Alternate Modules: Alternate versions of supported modules used for better hardware support or bug fixes. They are identified by an -alt suffix (e.g., broadcom-bnxt-en-alt). When installed, the kernel loads the alternate module instead of the supported one, though the supported driver remains on the system. Note: These receive less testing than supported modules.
    • Additional (Extra) Modules: Modules providing extra or experimental features (e.g., kmod-zfs for ZFS support or ceph-module for CephFS). Support levels vary; check the package description or XCP-ng wiki to determine if a module is experimental or officially supported.