Best posts made by samuelolavo | XCP-ng and XO forum

samuelolavo

Hello,

I’ve been configuring NUT on XCP-ng 8.3 and had some trouble finding proper documentation. However, after going through the messages in this forum, I created a document that I believe might help others set up the NUT client on XCP-ng 8.3:
https://github.com/samuel-olavo/xcp-ng-nutclient

This method worked for me — tested and confirmed.

Thanks everyone!

samuelolavo

Laravel Xen Orchestra v1.0.0 — An open-source PHP/Laravel client for the XO REST API

Hi everyone!

I’d like to share a small contribution to the XCP-ng and Xen Orchestra community: Laravel Xen Orchestra, an open-source package for integrating the XO REST API into PHP/Laravel applications.

The idea is to help other developers who use this ecosystem, make common integration tasks easier, and share something useful with the community. If you’re building an internal dashboard, an automation tool, or an application that interacts with Xen Orchestra, I hope this package can save you some time.

Here’s a simple example:

use SamuelOlavo\XenOrchestra\Laravel\Facades\Xo;

// List running VMs with the fields you need.
$vms = Xo::vms()
    ->fields(['id', 'name_label', 'power_state'])
    ->running()
    ->get();

// Start a VM and wait for the operation to finish.
Xo::vm($vmId)->start()->wait();

Version 1.0.0 targets Xen Orchestra 6.8.0 / REST API 0.39.0 and includes:

VM, host, pool, storage and network management.
Backup repository administration, schedules and logs.
Users, groups and role-based permissions.
Asynchronous task handling.
VM and disk imports/exports.
Events and subscriptions.
IPMI and SDN helpers when the corresponding plugins are available.

The package supports PHP 8.2+ and Laravel 12/13.

For transparency, the automated suite currently has 332 passing tests, run locally with PHP 8.4 and Laravel 13 using simulated API responses. This does not replace testing against a live Xen Orchestra installation, so feedback from different environments would be especially valuable.

Repository and documentation:
https://github.com/samuel-olavo/laravel-xen-orchestra

Version 1.0.0:
https://github.com/samuel-olavo/laravel-xen-orchestra/releases/tag/v1.0.0

This is an independent community project, released under the MIT license, and is not affiliated with Vates.

Suggestions, bug reports, pull requests and examples of how you use it are all welcome. If something could be clearer or work better, please let me know!

Thanks to the XCP-ng and Xen Orchestra teams, and to everyone contributing to this community. I hope this can be useful to others too.

samuelolavo

Hi,

I am trying to understand whether I am hitting a bug, a known limitation, or a configuration issue when using a large QCOW2 VDI on an LVM SR.

Environment

I have an existing VM with several virtual disks.

Most of the data disks are approximately 2 TiB and were created as VHD VDIs. They have been working correctly for a long time.

Example:

virtual-size: ~2 TiB
image-format: vhd
vdi_type: vhd

Inside the guest, several of these disks are combined using LVM to provide a larger filesystem.

The Xen Orchestra instance is built directly from source and kept up to date from the upstream source tree.

The storage repository involved is an existing local LVM SR that has been in production for several years. It was not newly created for this test and has been used successfully with VHD VDIs over that period.

I now need to add significantly more storage and would prefer to avoid continuing to add multiple ~2 TiB VHD disks.

I therefore created a new 15 TiB virtual disk using the current Xen Orchestra build.

The disk was automatically created as QCOW2:

virtual-size: 16492674416640
image-format: qcow2
vdi_type: qcow2
Storage Repository

The VDI is stored on the existing local LVM SR.

The SR has approximately:

Total size: ~44 TiB
Free after creating the new VDI: ~4 TiB

There was sufficient free space before creating the new 15 TiB VDI.

At the LVM level, the QCOW2 LV is present and has the expected size:

QCOW2-<uuid> ~15.00 TiB
Problem

When the 15 TiB QCOW2 disk is attached to the VM, the VM fails to start.

Xen Orchestra reports:

SR_BACKEND_FAILURE_46

The VDI is not available
[opterr=['XENAPI_PLUGIN_FAILURE',
'make_chain_rw',
'CommandException',
'Input/output error']]

The same VM starts normally when this QCOW2 VDI is removed or detached.

All the existing VHD disks on the same SR continue to work normally.

Relevant SMlog output

The Storage Manager detects the QCOW2 LV and can query its size.

For example:

blockdev --getsize64 /dev/<VG>/QCOW2-<uuid>

succeeds.

It also executes:

qemu-img measure \
-O qcow2 \
--output json \
-o cluster_size=65536 \
--size 16492674416640

successfully.

The failure happens during VDI activation:

BLKTAP2:<function VDI._activate_locked ...>:
EXCEPTION <class 'XenAPI.Failure'>,

['XENAPI_PLUGIN_FAILURE',
'make_chain_rw',
'CommandException',
'Input/output error']

self._make_chain_rw()

File "/opt/xensource/sm/LVMSR.py", line ..., in _make_chain_rw
raise Failure(result['ErrorDescription'])
Current VM disk layout

Simplified layout:

System disk VHD
Home disk VHD

~2 TiB VHD
~2 TiB VHD
~2 TiB VHD
~2 TiB VHD
~2 TiB VHD
~2 TiB VHD
~2 TiB VHD
~2 TiB VHD

15 TiB QCOW2 <-- new disk causing the failure

The existing VHD disks work correctly.

The problem only appeared after adding the large QCOW2 VDI.

Questions

Is a 15 TiB QCOW2 VDI on an existing local LVM SR expected to work reliably on current XCP-ng 8.3?

Is mixing VHD and QCOW2 VDIs on the same VM and on the same SR fully supported?

Could the fact that this is an older LVM SR created several years ago make any difference with the newer QCOW2 support?

Does the following error correspond to any known QCOW2/LVM issue?

make_chain_rw
CommandException
Input/output error

Are there specific minimum versions of xapi, sm, blktap, or other storage components required for large QCOW2 VDIs?

Would a different SR type be recommended for VDIs of this size, or should this configuration work normally?

The Xen Orchestra instance is built from source and kept current, so I am mainly trying to determine whether the issue is on the XCP-ng/storage side rather than the XO side.

I can provide additional anonymized SMlog, package versions, qemu-img output and LVM diagnostics if required.

Thanks.

samuelolavo

@poddingue
Thanks! That is a very good question.

For v1.0.0, the package targets Xen Orchestra 6.8.0 and REST API 0.39.0, which are the versions I used during development and testing.

My intention is to track API changes and keep compatibility documented per package release. I also agree that failing clearly is important: if an endpoint or response shape expected by the package is no longer available, the client should throw a descriptive exception rather than silently returning incomplete or misleading data.

I am still refining the version-compatibility strategy, but adding an explicit compatibility check and clearer exceptions for unsupported API behaviour is a good improvement to prioritise. Thank you for raising it.

Posts