This page describes infrastructure management in the XO 5 interface. XO 6 already covers inspection of pools, hosts, networks and storage, host power actions, network and VIF creation. See what lives where.
Xen Orchestra is built on one idea: a single interface for all your pools, hosts and VMs, from any device: creation, modification, metrics and statistics for every object of your XCP-ng infrastructure. This page covers those day-to-day operations in XO 5.
The home view is what you see when you access your Xen Orchestra URL. It displays all running VMs. This can be configured to your needs (see the "Filters section" below).
If you don't have any servers connected, you'll see a panel telling you to add a server:
zoomed detailNo host connected yet: add your first server to get started
By default, this view groups all running VMs on your connected server and everyday administration tasks:
https://your-xo/v5/#/home
The Home view lists every VM across all your connected pools
Let's take a quick tour:
the global menu is on the left, you can collapse it by clicking on the icon
the home view has a header with a type selector (VMs, hosts or pools), a filter zone and a button to create new VMs
the VM list also has a header (number of filtered VMs and total VMs) and assisted filters (by pool, host and tags) and a sort menu (by name, memory etc.). You can also expand all VMs details here with the icon
tip
You can edit a VM name, description and even current host by long clicking on the field
You have power status, name, description, number of CPU cores, total memory, management IP and pool name displayed. You can also edit these by long clicking.
tip
If hosts have missing patches, you'll see a red dot with the total patches missing. Click on it to go the patch section of the host. See this blog post on patches for XenServer for more details.
The idea is not just to provide a good search engine, but also a complete solution for managing all your XCP-ng/XenServer infrastructure. Ideally:
less clicks to see or do what you need
find a subset of interesting objects
perform bulk actions on all results found
sort your results for more pertinent insight
tip
Pro Tip: the URL of Xen Orchestra contains the search string, eg home?s=power_state%3Arunning+. You can share these URLs to your colleagues to share your search!
There isn't much documentation listing these (yet), but you can see all objects and their properties using xo-cli list-objects. You can then use these properties for search in XOA.
What is a XCP-ng/XenServer template? It can be 2 things: first an "empty" template, meaning it contains only the configuration for your future VM, such as example settings (minimum disk size, RAM and CPU, BIOS settings if HVM etc.) Or it could be a previous VM you converted into a template: in this case, creating a VM will clone the existing disks.
You can create multiple VMs at once by toggling the Multiple VMs option. The {name} pattern is the "Name" field of the VM. By default, it will start with number 1 and increment up. You can change this via the "First index" field.
Click on the refresh icon to see the change:
zoomed detailCreate several identical VMs in one go
The default CPU weight is 256 which means it will be scheduled by Xen like any other VMs on the host it runs from. If you raise it, eg with 512, CPUs on this VM will be scheduled with twice the priority as others. If you decrease it, with 64 for example, it will be scheduled with 4 times less priority.
What about cap? It's the maximum amount of CPUs a VM can consume, using a 100 base (1 vCPU: 100). Default is 0 and means no upper cap.
tip
Should I mess with these settings? In general: nope. Change this only if you are sure of what are you doing. More can be found here: https://wiki.xen.org/wiki/Credit_Scheduler
These templates will use PV configuration in order to boot: either from the right ISO or network URL. PV Args can be used to modify kernel parameters, but it's a very advanced setting you shouldn't play with.
Because there is already disks installed, you shouldn't have "Install settings" per se. But you can use our config drive setup if your template already has CloudInit installed!
This is the network section of the VM configuration: in general, MAC field is kept empty (autogenerated from XCP-ng/XenServer). We also select the management network by default, but you can change it to reflect your own network configuration.
This section is for configuring new or existing disks (according to your selected template).
tip
Pro tip: avoid using large disks for your VMs. Want to store a lot of files? Use a network share for that (NFS, SMB) and keep using VMs with small system disks. It's far easier to maintain, migrate, backup and restore!
Each VM has a maximum vCPU number. This value can't be changed while the VM is running. You can reduce the number of vCPUs, but you can't assign more than the set max. In XO, while your VM is halted, set the max vCPUs you would need, then boot it. Now you can reduce it and then expand it later to this maximum.
Thanks to Xen Storage Motion, it's easy to move a VM disk from one storage location to another, while the VM is running! This feature can help you migrate from your local storage to a SAN, or just upgrade your SAN without any downtime.
To do so: Access the Xen Orchestra page for your running VM, then enter the Disk tab. Long click on the current SR of the disk, and a drop down menu will be displayed with all compatible destinations. Just select one, that's all: the migration will start live!
zoomed detailMigrate a disk to another SR, live, from the VM Disks tab
In the advanced tab, use the "Recovery Start" button:
zoomed detailStart the VM in recovery mode from its Advanced tab
This button will allow you to boot directly from the CD drive, ignoring your current disks. Note that it works for all virtualization modes: HVM or PV.
Activating "Auto Power on" for a VM will also configure the pool accordingly. If your host is rebooted, the VM will be started right after the host is up.
In the Vates stack, each VM connects to the network through a Virtual Interface, or VIF.
Think of it as the VM’s virtual network card: it handles all incoming and outgoing traffic on a specific virtual network, which is linked to a physical NIC on the host via a bridge. Every VIF comes with a fixed MAC address and can be tied to a particular VLAN (or virtual network), depending on how your environment is set up.
VIF locking mode is a security feature that helps prevent unauthorized or spoofed traffic from getting in or out of a VM.
In practical terms, enabling locking mode means the VM can’t send traffic using a fake MAC address, and if an IP address is set, it won’t be able to use anything else either. This is especially helpful in multi-tenant setups or anytime you need tight control over which VM is allowed to do what on the network.
By default, VIFs are not locked. Users can assign any IP address to their VM, and they will work without restriction.
However, if you add restricted IPs, the VIF becomes locked, meaning only the specified IP addresses are allowed to send traffic outside the VM.
Head over to the Network tab to see each VIF along with its current locking mode status:
zoomed detailThe VIF locking status in the VM Network tab
To change the locking mode status:
Click the pencil icon (with the Edit locking mode label). A dropdown menu appears.
Choose your desired mode from that menu:
zoomed detailChoose the locking mode of a VIF
If Xen Orchestra knows the VM’s IP address (either through the guest agent or DHCP), it will automatically apply IP-level locking when the mode is enabled.
If your pool supports HA (must have shared storage), you can activate "HA". Read the XCP-ng documentation for more details on High Availability with XCP-ng.
In the VM's Advanced tab, you can choose between three HA modes:
Restart: a protected VM cannot be immediately restarted after a server failure. HA will attempt to restart the VM when additional capacity becomes available in the pool.
Best-Effort: for VMs configured with best-effort, HA will try to restart them on another host if their original host goes offline. This attempt occurs only after all VMs set to the "restart" mode have been successfully restarted. HA will make only one attempt to restart a best-effort VM; if it fails, no further attempts will be made.
Disabled: if an unprotected VM or its host is stopped, HA does not attempt to restart the VM.
tip
In Xen Orchestra, you can filter to see which VMs are in which mode:
high_availability:restart or high_availability:best-effort
VM copy allows you to make an export and an import via streaming. You can target any SR in your whole XCP-ng/XenServer infrastructure (even across different pools!)
Just access the page for the VM that you want to export, and click on the "Export" button in the toolbar. You'll instantly download a compressed XVA file.
It works even if the VM is running, because we'll automatically export a snapshot of this VM.
In simple migration, the VM's active state is transferred from host A to host B while its disks remains in its original location. This feature is only possible when the VM's disks are on a shared SR by both hosts and if the VM is running.
Migrate a VM within the same pool from host A to host B without moving the VM's VDIs.
VM Migration with Storage Motion (VM.migrate_send)
VM migration with storage motion allows you to migrate a VM from one host to another when the VM's disks are not on a shared SR between the two hosts or if a specific network is chosen for the migration. VDIs will be migrated to the destination SR if one is provided.
Migrating a VM that has VDIs on a shared SR from host A to host B must trigger a "Simple VM Migration".
Migrating a VM that has VDIs on a shared SR from host A to host B using a particular network must trigger a "VM Migration with Storage Motion" without moving its VDIs.
Migrating a VM from host A to host B with a destination SR must trigger a "VM Migration with Storage Motion" and move VDIs to the destination SR, regardless of where the VDIs were stored.
XCP-ng is a type 1 hypervisor, similar to VMware ESXi.
You can migrate your VM from VMware vSphere to a Vates environment (Xen Orchestra and XCP-ng), directly from Xen Orchestra. For this, we use V2V ("VMware to Vates").
Outside updates (see next section), you can also do host management via Xen Orchestra. Basic operations are supported, like reboot, shutdown and so on.
But there's also some specific things, like Maintenance mode.
You can easily adjust the control domain memory under the Advanced tab of a host. Enable the maintenance mode on the host and click on the pen icon to edit the value:
zoomed detailEdit the Dom0 memory from the host Advanced tab
There is more information about Dom0 memory management in the XCP-ng Documentation
Xen Orchestra is here to help you to manage all your pools and hosts updates. Note there's a difference on updates between XCP-ng and Citrix Hypervisor, since they are not using the same mechanism. However, the view on available updates and updating is very similar.
tip
Updates can be called both "patches" or "updates", it doesn't matter. Updates are distributed via an ISO file containing RPMs for Citrix Hypervisor, while in XCP-ng they are just traditional RPMs hosted in a central repository and its mirrors, like a regular Linux distribution.
You'll be notified by Xen Orchestra directly in the main XO menu (on the left), with a yellow triangle:
zoomed detailThe number of missing patches, right on the pool
If you hover on it, it will explain that updates/patches are available.
You can also see how many updates to do in the Home/Pool view for your pools, and Home/Host view for your hosts, with a red pill. In this following screenshot, "Test Pool1" got 88 updates available:
zoomed detailMissing patches listed for the host
You can also see the available updates in the Dashboard view.
Xen Orchestra will request a plugin, bundled and hosted within your XCP-ng hosts. This plugin will query the status of updates. Then, when the update will be applied, it's also the plugin that will download and apply them.
So unlike with Citrix Hypervisor, Xen Orchestra will not fetch or download updates, but it will order the host to do it by itself. Be sure that your host(s) can access the update repositories.
Also known as RPU, this is the advised way to update your pool. By just clicking on one button, Xen Orchestra will automatically move VMs around, apply updates and reboot the hosts, without any service interruption. The following button is available in the Pool view of the Patches tab:
zoomed detailThe Rolling Pool Update button on the pool Patches tab
tip
This powerful and fully automated mechanism requires some prerequisites: all your VMs disks must be on a one (or more) shared storage. Also, high-availability will be automatically disabled, as the XO load balancer plugin and backup jobs. Everything will be enabled back when it's done!
warning
XO will restart the hosts one by one and wait for each host to be up and running before continuing. However, if the host takes too much time to boot, the RPU will fail with an error. By default, XO will wait up to 20 minutes before failing. You can change that value in your xo-server config:
[xapiOptions]
restartHostTimeout='40 minutes'
zoomed detailXO orchestrates everything: evacuate, patch, reboot, repeat on each host
You can schedule rolling pool updates to automate the patching and rebooting of your pools during off-peak hours.
tip
Of course, schedule the updates outside production hours. Although RPUs are designed to be transparent, it is always wise to schedule some buffer time in case something goes wrong.
Create a job: Navigate to the Jobs screen and create a new job, using the pool.rollingUpdate method. Determine which pools you want to include in the update:
zoomed detailCreate a scheduled Rolling Pool Update job
Set the schedule: Assign a schedule to the job (e.g., every Sunday at 3 AM) and apply it to your new job:
zoomed detailPick the schedule for your Rolling Pool Update
Monitor the process: Once scheduled, the RPU will run automatically at the set time, applying updates and rebooting hosts as necessary.
XO keeps a full trace of each rolling pool update/reboot on disk. So even if xo-server crashed in the middle of a run, you can still find out what happened and where it stopped.
Each run writes two files in <datadir>/rpu-traces (on XOA: /var/lib/xo-server/data/rpu-traces):
rpu-<poolId>-<timestamp>.ndjson: the trace. One JSON line per event: steps, progress, VM migrations, errors. Lines are written synchronously, so the file stays readable even after a crash.
rpu-<poolId>-<timestamp>.heartbeat.json: rewritten every 5 seconds with the current status, as long as the run is alive.
The path of the trace file is logged in journalctl -u xo-server when the RPU starts. You'll also find it on the task itself, as the traceFile property in the tasks view.
A heartbeat stuck on "status": "pending" with an old lastUpdated means the run died mid-flight. When xo-server comes back, it marks the task as interrupted, stamps the heartbeat with the last time the run was alive, and logs a line pointing at the trace.
There's no resume yet: just launch the RPU again. Hosts that were already patched have nothing left to install, so the new run goes through them quickly.
tip
Only one RPU or rolling pool reboot can run at a time on a given pool. A second attempt is rejected with an explicit error, not queued.
Traces are deleted after 31 days. Both the folder and the retention can be changed in your xo-server config:
If you can't use RPU (Rolling Pool Updates), you can still use "Install pool patches" button. This will simply install updates on all hosts on your pool and restart the toolstack, without doing any host reboot:
zoomed detailInstall all pool patches in one click
tip
Restarting the toolstack won't have any impact on your running VMs. However, most updates will require a reboot to be applied, that you should execute during a scheduled maintenance.
You can see hosts that will require a reboot via a small blue triangle:
We do NOT recommend to install updates to individual hosts. Obviously except if they are alone in their own pool. Running hosts in the same pool with different level of updates should be avoided as possible. We leave that option in case you have a specific need, but again, we discourage that usage as possible. Note that even a host alone in its pool can be updated via the "Pool update" button!
Xen Orchestra will directly request a specific XML, hosted by Citrix. It will be analyzed and compared to the patch level on your hosts.
If there's available/missing updates, XO will download it directly, then send it to the pool, and finally ask the pool to apply it. In that scenario, you should check if Xen Orchestra can access outside to get those updates.
As specified in the documentation your pool shouldn't consist of hosts from different CPU vendors.
warning
Even with matching CPU vendors, in the case of different CPU models, XCP-ng/Citrix Hypervisor will "level" down to use the CPU having the least instructions.
All the hosts in a pool must run the same XCP-ng version.
First you should add your new host to XOA by going to New > Server as described in the relevant chapter.
When you add your host to XOA a pool will automatically be created for it, taking the host name as the default pool name. The pool name can be edited to match your needs.
To edit the name of your pool go to Home > Pools and long click on the pool name to edit it.
If you need to add a new host to a pool, first you need to add your new host to your XOA by going to New > Server as described in the relevant chapter.
Then you need to add the new host to the desired pool. Navigate to Home > Pools, and click on the desired pool. Then in the top right, click the Add Hosts button and select your new host.
Network bonding, also known as link aggregation, involves combining two or more physical network interfaces into a single logical interface.
The primary goals are to improve redundancy, so that a single cable or interface failure does not interrupt connectivity— and, depending on the bonding mode, to increase throughput by distributing traffic across multiple links.
Navigate to New → Network to open the Create Network page.
Choose the pool where you want the bond to be created.
Enable the Bonded network toggle:
zoomed detailCreate a bonded network from the pool Network tab
In the Interface dropdown, select two or more physical interfaces (PIFs) to include in the bond.
Provide a name and a description for the bond.
Set the Bond mode to LACP.
Leave the MTU field blank. This will work as-is in most cases.
Click Create network.
XO will then create the bond on the host(s):
zoomed detailThe bond and its member interfaces
tip
If applied to a pool, the bond is created across all pool members, so make sure all your pool members are cabled and configured on the switch side for LACP!
If the host’s management interface resides on one of the selected interfaces, XO will automatically migrate the management interface on top of the new bond (e.g., if management was on eth0 and the bond consists of eth0 + eth1).
Once a bond (e.g., bond0) is created, you can build VLANs over it:
Go again to New → Network screen.
Select the new bond interface (e.g., bond0) in the Interface dropdown.
Provide a name, description, and specify the VLAN ID (for instance, 20):
zoomed detailCreate a VLAN network on top of the bond
Validate the VLAN network creation.
This creates a virtual network on top of the bond, using the name and ID you've specified, available for VM attachment.
tip
This process is the same whether you're adding a VLAN on top of a LACP network bond, or a bond in another mode (such as Active/Active or Active/Backup).
Need to shutdown your storage for maintenance? In the SR's Advanced tab, use the "Enable maintenance mode" button.
Maintenance mode will trigger two actions internally:
shutdown related VMs
disconnect the storage from your hosts
zoomed detailEnable maintenance mode on a storage repository
This way, you can do whatever is needed on the storage, and when done, re-enable it: all the hosts will be reconnected to it. No manual process to find all VMs related to this SR, shut them down, then disconnect all the PBDs.
The dashboard view gathers information on all your connected pools/hosts.
note
Since XO 6 became the default interface, https://your-xo/#/dashboard opens the new XO 6 dashboard. The XO 5 dashboard described here now lives under /v5/.
https://your-xo/v5/#/dashboard/overview
The Overview aggregates pools, hosts, VMs, resource usage and alarms at a glance
tip
You can also update all your hosts (install missing patches) from this page.
A Parallel Coordinates visualization helps to detect proportions in a hierarchical environment. In a XCP-ng/XenServer environment, it's especially useful if you want to see useful information from a large amount of data.
https://your-xo/v5/#/dashboard/visualizations
Follow a resource path across vCPUs, RAM, network and storage
This section shows the disks, their size and used space. A progress bar helps you to quickly identify when a disk becomes full as it turns orange (80%) and then red (91%).
If your infrastructure works properly, this view should be empty. If not, the causes of unhealthy VDIs can be numerous and we recommend you open a support ticket.
Having VDIs attached to the control domain during a backup job is normal, but not when it's finished. You can detach them by clicking on the Forget button, this will remove the virtual cable between the host and the disk without removing the disk. If the problem occurs on a regular basis, we recommend you open a support ticket.
VMs snapshots that do not have parents are usually automatically deleted. If not, they can be removed using the trash icon and should be considered abnormal in a production environment.
List of the VMs with more than the recommended amount of snapshots (3). There is no hard limit, but as the chain becomes longer, this can lead to poorer performances during the process of reading the VMs snapshots.
Xen Orchestra lets you monitor the usage of some or all of your resources by sending regular reports via email.
To receive reports, you first need to enable the usage-report plugin:
Go to Settings → Plugin. A list of plugins will appear.
From the list, look for the usage-report plugin (you can scroll through the list or search for it by name).
Enable the plugin by switching on the toggle next to the plugin name.
Click the + icon to open the plugin settings:
zoomed detailA usage report generated by the plugin
In the emails section, click Add. A new text field will appear.
Enter the email address where you want to receive the reports. Repeat steps 5–6 to add more addresses.
Turn on the all toggle to include stats for all resources in your report, including:
VMs
Hosts
Storage repositories
tip
To include these stats in your reports, the plugin must have saved them at least once.
::: 8. In the periodicity dropdown, choose whether you want to receive reports daily, weekly, or monthly.
9. Click Save configuration. Reports will be sent to the email addresses you entered at the frequency you selected.
Software RAID in the Vates stack is managed using mdadm.
mdadm is a Linux utility used to manage and monitor software RAID devices. It is used in modern Linux distributions in place of older software RAID utilities such as raidtools2 or raidtools.
We strongly recommend using a hardware RAID solution over software RAID whenever possible.
warning
Software RAID integration is provided as-is, with no official support.
We do not offer support for issues arising from the use of software RAID for your storage repositories.
If you encounter issues with your software RAID array, you can find answers regarding disk replacement at the Troubleshooting section in the XCP-ng documentation.
If a host has a degraded software RAID array, a red warning triangle will appear in the host view. Clicking on it will display detailed information about the issue, so you can quickly identify and address critical problems:
zoomed detailXO raises an alert when the RAID array is degraded
