S
Offline
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!
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:
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.
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.
@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. 
@dthenot
Thanks. I checked this on the pool master.
Interestingly, there is no make_chain_rw entry in /var/log/SMlog on the pool master itself.
On the host where the VM and the storage reside, /var/log/SMlog shows the QCOW2 VDI activation reaching make_chain_rw and then failing with:
XENAPI_PLUGIN_FAILURE
make_chain_rw
CommandException
Input/output error
One detail that may be relevant: this is a local LVM SR. The SR belongs to the host where the VM is running, and that host is not the pool master. The VG for this SR is therefore not present on the pool master.
The existing VHD VDIs on the same local LVM SR continue to activate normally; the failure occurs with the new QCOW2 VDI.
I also checked dmesg on the host owning the SR and I do not see any corresponding disk/RAID I/O errors at the time of the failure.
For reference, Xen Orchestra is built from source and is currently at commit:
faf6745471d7b2a00d774d98428873455e9539dc
Could the fact that this is a local LVM SR on a non-master host be relevant to how make_chain_rw is being handled?
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.
@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.
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:
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.
@yannsionneau Hi,
Sorry for the delay...
menuentry 'XCP-ng' {
search --label --set root root-zrxcsq
multiboot2 /boot/xen.gz dom0_mem=8192M,max:8192M watchdog ucode=scan dom0_max_vcpus=1-16 crashkernel=256M,below=4G console=vga vga=mode-0x0311
module2 /boot/vmlinuz-4.19-xen root=LABEL=root-zrxcsq ro nolvm hpet=disable console=hvc0 console=tty0 quiet vga=785 splash plymouth.ignore-serial-consoles xen-pciback.hide=(0000:03:00.0)
module2 /boot/initrd-4.19-xen.img
}
03:00.0 VGA compatible controller: NVIDIA Corporation GB202GL [RTX PRO 6000 Blackwell Max-Q Workstation Edition] (rev a1) (prog-if 00 [VGA controller])
Subsystem: NVIDIA Corporation Device 204c
Physical Slot: 10
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Interrupt: pin A routed to IRQ 89
Region 0: Memory at f4000000 (32-bit, non-prefetchable) [disabled] [size=64M]
Region 1: Memory at 70060000000 (64-bit, prefetchable) [disabled] [size=256M]
Region 3: Memory at 70070000000 (64-bit, prefetchable) [disabled] [size=32M]
Region 5: I/O ports at 1000 [disabled] [size=128]
Expansion ROM at f8000000 [disabled] [size=512K]
Capabilities: [40] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold-)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [48] MSI: Enable- Count=1/16 Maskable+ 64bit+
Address: 0000000000000000 Data: 0000
Masking: 00000000 Pending: 00000000
Capabilities: [60] Express (v2) Legacy Endpoint, MSI 00
DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s <64ns, L1 unlimited
ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset+
DevCtl: Report errors: Correctable+ Non-Fatal+ Fatal+ Unsupported-
RlxdOrd+ ExtTag+ PhantFunc- AuxPwr- NoSnoop+ FLReset-
MaxPayload 256 bytes, MaxReadReq 512 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
LnkCap: Port #0, Speed unknown, Width x16, ASPM L1, Exit Latency L0s unlimited, L1 unlimited
ClockPM+ Surprise- LLActRep- BwNot- ASPMOptComp+
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed unknown, Width x4, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
DevCap2: Completion Timeout: Range AB, TimeoutDis+, LTR+, OBFF Via message
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR+, OBFF Via WAKE#
LnkCtl2: Target Link Speed: Unknown, EnterCompliance- SpeedDis-
Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete+, EqualizationPhase1+
EqualizationPhase2+, EqualizationPhase3+, LinkEqualizationRequest-
Capabilities: [9c] Vendor Specific Information: Len=14 <?>
Capabilities: [100 v1] #19
Capabilities: [12c v1] Latency Tolerance Reporting
Max snoop latency: 1048576ns
Max no snoop latency: 1048576ns
Capabilities: [134 v1] #15
Capabilities: [14c v1] #25
Capabilities: [158 v1] #26
Capabilities: [188 v1] #2a
Capabilities: [1b8 v2] Advanced Error Reporting
UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq+ ACSViol-
UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO+ CmpltAbrt- UnxCmplt+ RxOF+ MalfTLP+ ECRC+ UnsupReq- ACSViol-
CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn-
Capabilities: [200 v1] #27
Capabilities: [248 v1] Alternative Routing-ID Interpretation (ARI)
ARICap: MFVC- ACS-, Next Function: 1
ARICtl: MFVC- ACS-, Function Group: 0
Capabilities: [2a4 v1] Vendor Specific Information: ID=0001 Rev=1 Len=014 <?>
Capabilities: [2bc v1] Power Budgeting <?>
Capabilities: [2f4 v1] Device Serial Number 18-a6-fe-7f-8f-2d-b0-48
Kernel driver in use: pciback
03:00.1 Audio device: NVIDIA Corporation Device 22e8 (rev a1)
Subsystem: NVIDIA Corporation Device 0000
Physical Slot: 10
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin B routed to IRQ 10
Region 0: Memory at f8080000 (32-bit, non-prefetchable) [size=16K]
Capabilities: [40] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [48] MSI: Enable- Count=1/1 Maskable+ 64bit+
Address: 0000000000000000 Data: 0000
Masking: 00000000 Pending: 00000000
Capabilities: [60] Express (v2) Endpoint, MSI 00
DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s <64ns, L1 unlimited
ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset- SlotPowerLimit 75.000W
DevCtl: Report errors: Correctable+ Non-Fatal+ Fatal+ Unsupported-
RlxdOrd+ ExtTag+ PhantFunc- AuxPwr- NoSnoop+
MaxPayload 256 bytes, MaxReadReq 512 bytes
DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr- TransPend-
LnkCap: Port #0, Speed unknown, Width x16, ASPM L1, Exit Latency L0s unlimited, L1 unlimited
ClockPM+ Surprise- LLActRep- BwNot- ASPMOptComp+
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed unknown, Width x4, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
DevCap2: Completion Timeout: Range AB, TimeoutDis+, LTR+, OBFF Via message
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled
LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete-, EqualizationPhase1-
EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
Capabilities: [9c] Vendor Specific Information: Len=14 <?>
Capabilities: [100 v1] #25
Capabilities: [10c v2] Advanced Error Reporting
UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq+ ACSViol-
UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq+ ACSViol-
UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO+ CmpltAbrt- UnxCmplt+ RxOF+ MalfTLP+ ECRC+ UnsupReq- ACSViol-
CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn-
Capabilities: [154 v1] Alternative Routing-ID Interpretation (ARI)
ARICap: MFVC- ACS-, Next Function: 0
ARICtl: MFVC- ACS-, Function Group: 0
09:00.0 Non-Essential Instrumentation [1300]: Advanced Micro Devices, Inc. [AMD] Genoa/Bergamo Dummy Function (rev 01)
Subsystem: Advanced Micro Devices, Inc. [AMD] Genoa/Bergamo Dummy Function
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Capabilities: [48] Vendor Specific Information: Len=08 <?>
Capabilities: [50] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [64] Express (v2) Endpoint, MSI 00
DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s <4us, L1 unlimited
ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset+ SlotPowerLimit 0.000W
DevCtl: Report errors: Correctable+ Non-Fatal+ Fatal+ Unsupported-
RlxdOrd+ ExtTag+ PhantFunc- AuxPwr- NoSnoop+ FLReset-
MaxPayload 128 bytes, MaxReadReq 512 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
LnkCap: Port #0, Speed unknown, Width x16, ASPM L0s L1, Exit Latency L0s <64ns, L1 <1us
ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp+
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed unknown, Width x16, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
DevCap2: Completion Timeout: Range ABCD, TimeoutDis+, LTR-, OBFF Not Supported
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled
LnkCtl2: Target Link Speed: Unknown, EnterCompliance- SpeedDis-
Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -3.5dB, EqualizationComplete-, EqualizationPhase1-
EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
Capabilities: [100 v1] Vendor Specific Information: ID=0001 Rev=1 Len=010 <?>
Capabilities: [270 v1] #19
Capabilities: [328 v1] Alternative Routing-ID Interpretation (ARI)
ARICap: MFVC- ACS-, Next Function: 1
ARICtl: MFVC- ACS-, Function Group: 0
Capabilities: [410 v1] #26
Capabilities: [450 v1] #27
Capabilities: [500 v1] #2a
xe pci-list
uuid ( RO) : 73708288-55ec-b17f-ba73-6d2c116b3bbc
vendor-name ( RO): NVIDIA Corporation
device-name ( RO): GB202GL [RTX PRO 6000 Blackwell Max-Q Workstation Edition]
pci-id ( RO): 0000:03:00.0
uuid ( RO) : c94f0327-8c86-3aa8-dd7c-9389ae1123f5
vendor-name ( RO): Intel Corporation
device-name ( RO): Ethernet Controller X550
pci-id ( RO): 0000:81:00.1
uuid ( RO) : 09e0f3b1-18bb-8a6e-97d8-0209a8e4a97c
vendor-name ( RO): Advanced Micro Devices, Inc. [AMD]
device-name ( RO): FCH SATA Controller [AHCI mode]
pci-id ( RO): 0000:0a:00.1
uuid ( RO) : cc5feb5c-b8aa-a975-de76-513d309f8e73
vendor-name ( RO): Intel Corporation
device-name ( RO): Ethernet Controller X550
pci-id ( RO): 0000:41:00.0
uuid ( RO) : 72baa4c2-13b3-22fb-cc87-b10033ccb025
vendor-name ( RO): Broadcom / LSI
device-name ( RO): MegaRAID 12GSAS/PCIe Secure SAS39xx
pci-id ( RO): 0000:c1:00.0
uuid ( RO) : d2d40d25-4b69-7f6a-a8e2-3101ad80fcb6
vendor-name ( RO): Intel Corporation
device-name ( RO): Ethernet Controller X550
pci-id ( RO): 0000:41:00.1
uuid ( RO) : 630bdaee-0e03-b8a1-c726-4f34230e89f7
vendor-name ( RO): Intel Corporation
device-name ( RO): Ethernet Controller X550
pci-id ( RO): 0000:81:00.0
uuid ( RO) : d4023077-83fe-a0b7-5f3f-516204c2c1d1
vendor-name ( RO): Advanced Micro Devices, Inc. [AMD]
device-name ( RO): FCH SATA Controller [AHCI mode]
pci-id ( RO): 0000:ce:00.1
uuid ( RO) : c67855cd-4908-0711-7424-a6db2eb011f0
vendor-name ( RO): Advanced Micro Devices, Inc. [AMD]
device-name ( RO): FCH SATA Controller [AHCI mode]
pci-id ( RO): 0000:0a:00.0
uuid ( RO) : ef1d93e4-e82b-c33c-a488-8f7a9129eb8a
vendor-name ( RO): NVIDIA Corporation
device-name ( RO): Device 22e8
pci-id ( RO): 0000:03:00.1
uuid ( RO) : b6235c56-4070-dc4d-9db2-5e361f38d2b2
vendor-name ( RO): Advanced Micro Devices, Inc. [AMD]
device-name ( RO): FCH SATA Controller [AHCI mode]
pci-id ( RO): 0000:ce:00.0
uuid ( RO) : 5c7258ae-504b-9ac4-8b16-7129b8d8455d
vendor-name ( RO): ASPEED Technology, Inc.
device-name ( RO): ASPEED Graphics Family
pci-id ( RO): 0000:cc:00.0
xl pci-assignable-list
0000:03:00.0
Model: Supermicro AS-2015CS-TNR
@GuillaumeHullin Hi,
I don't know if you're using Nut to control the UPS, but if so, you can check out this guide on how to use Nut with XCP: https://github.com/samuel-olavo/xcp-ng-nutclient.
Thank you very much!
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!
Hi everyone,
I have an XCP-ng pool with High Availability (HA) enabled. Normally, when I issue a shutdown command on a host (either via xe host-shutdown or from Xen Orchestra), the system automatically starts migrating all VMs to other hosts in the pool — which makes sense for HA.
However, in my case, I’m integrating the hosts with a central UPS monitoring system (NUT), and during a power outage, I need to force a host to shut down immediately — without triggering VM migrations, even if HA is currently active.
Is there any CLI command or parameter that allows a clean, immediate shutdown of a specific host without migration attempts, or any way to temporarily suppress HA’s automatic evacuation logic for a given shutdown action?
I’m aware that disabling HA entirely (xe pool-ha-disable) before shutdown would work, but I’m looking for a faster or more direct way, ideally per-host, not affecting the whole pool.
Any suggestions or best practices for this type of emergency power management setup?
Thanks in advance!
— Samuel Olavo
I have a the XCP8.3 installed.
Xen Orchestra, commit bcee5 .
When I add it manually, the audio, for example, it asks for a reboot, but then, when I restart the server, it has another pci ID, and another ID.
Thank you for your reply.
I followed your instructions; however, when I passthrough the GPU NVIDIA on the XenOrchestra and he same error occurs when I reboot.
Change the PCI and UUID of the graphics card to the one before rebooting.