Finally just finished our migration from VMware to XCP-NG.
VMs - 34 mix windows server and ubuntu linux.
Pools - 3
Host - 6
Dell R660 - 2
Dell R640 - 4
A
Online
-
Migration from VMware to XCP-NG complete.
-
RE: XCP-ng 8.3 updates announcements and testing
Installed patches on home lab. No initial issues found. Existing Windows 11 vm no issues with it on basic vm functions. Created new Windows 11 vm with 26h2 iso no issues. Also installed guest tools in both vms.
-
RE: XCP-ng 8.3 updates announcements and testing
Installed...
Updated: blktap.x86_64 0:3.55.5-9.4.xcpng8.3 forkexecd.x86_64 0:26.1.16-1.2.xcpng8.3 message-switch.x86_64 0:26.1.16-1.2.xcpng8.3 qcow-stream-tool.x86_64 0:26.1.16-1.2.xcpng8.3 rrdd-plugins.x86_64 0:26.1.16-1.2.xcpng8.3 sm.x86_64 0:3.2.12-23.5.xcpng8.3 sm-cli.x86_64 0:26.1.16-1.2.xcpng8.3 sm-fairlock.x86_64 0:3.2.12-23.5.xcpng8.3 squeezed.x86_64 0:26.1.16-1.2.xcpng8.3 varstored-guard.x86_64 0:26.1.16-1.2.xcpng8.3 vhd-tool.x86_64 0:26.1.16-1.2.xcpng8.3 wsproxy.x86_64 0:26.1.16-1.2.xcpng8.3 xapi-core.x86_64 0:26.1.16-1.2.xcpng8.3 xapi-nbd.x86_64 0:26.1.16-1.2.xcpng8.3 xapi-rrd2csv.x86_64 0:26.1.16-1.2.xcpng8.3 xapi-storage-script.x86_64 0:26.1.16-1.2.xcpng8.3 xapi-tests.x86_64 0:26.1.16-1.2.xcpng8.3 xapi-xe.x86_64 0:26.1.16-1.2.xcpng8.3 xcp-networkd.x86_64 0:26.1.16-1.2.xcpng8.3 xcp-rrdd.x86_64 0:26.1.16-1.2.xcpng8.3 xenopsd.x86_64 0:26.1.16-1.2.xcpng8.3 xenopsd-cli.x86_64 0:26.1.16-1.2.xcpng8.3 xenopsd-xc.x86_64 0:26.1.16-1.2.xcpng8.3 -
RE: XCP-ng 8.3 updates announcements and testing
We pushed the tested packages along a xen security update to the xcp-ng-updates repository, check blog post for summary and related advisories:
https://xcp-ng.org/blog/2026/07/28/july-2026-updates-1-for-xcp-ng-8-3-lts/Just updated my homelab hosts.
[10:45 xcp-ng-disjqdnc ~]# yum clean metadata Loaded plugins: fastestmirror Cleaning repos: xcp-ng-base xcp-ng-updates 6 metadata files removed 4 sqlite files removed 0 metadata files removed [10:45 xcp-ng-disjqdnc ~]# yum update Loaded plugins: fastestmirror Loading mirror speeds from cached hostfile Excluding mirror: updates.xcp-ng.org * xcp-ng-base: mirrors.xcp-ng.org Excluding mirror: updates.xcp-ng.org * xcp-ng-updates: mirrors.xcp-ng.org xcp-ng-base/signature | 473 B 00:00:00 xcp-ng-base/signature | 3.0 kB 00:00:00 !!! xcp-ng-updates/signature | 473 B 00:00:00 xcp-ng-updates/signature | 3.0 kB 00:00:00 !!! (1/2): xcp-ng-base/primary_db | 3.9 MB 00:00:00 (2/2): xcp-ng-updates/primary_db | 1.6 MB 00:00:01 Resolving Dependencies --> Running transaction check ---> Package xen-dom0-libs.x86_64 0:4.17.6-9.3.xcpng8.3 will be updated ---> Package xen-dom0-libs.x86_64 0:4.17.6-9.3.1.xcpng8.3 will be an update ---> Package xen-dom0-tools.x86_64 0:4.17.6-9.3.xcpng8.3 will be updated ---> Package xen-dom0-tools.x86_64 0:4.17.6-9.3.1.xcpng8.3 will be an update ---> Package xen-hypervisor.x86_64 0:4.17.6-9.3.xcpng8.3 will be updated ---> Package xen-hypervisor.x86_64 0:4.17.6-9.3.1.xcpng8.3 will be an update ---> Package xen-libs.x86_64 0:4.17.6-9.3.xcpng8.3 will be updated ---> Package xen-libs.x86_64 0:4.17.6-9.3.1.xcpng8.3 will be an update ---> Package xen-tools.x86_64 0:4.17.6-9.3.xcpng8.3 will be updated ---> Package xen-tools.x86_64 0:4.17.6-9.3.1.xcpng8.3 will be an update --> Finished Dependency Resolution Dependencies Resolved ============================================================================================================================================ Package Arch Version Repository Size ============================================================================================================================================ Updating: xen-dom0-libs x86_64 4.17.6-9.3.1.xcpng8.3 xcp-ng-updates 704 k xen-dom0-tools x86_64 4.17.6-9.3.1.xcpng8.3 xcp-ng-updates 2.0 M xen-hypervisor x86_64 4.17.6-9.3.1.xcpng8.3 xcp-ng-updates 2.4 M xen-libs x86_64 4.17.6-9.3.1.xcpng8.3 xcp-ng-updates 66 k xen-tools x86_64 4.17.6-9.3.1.xcpng8.3 xcp-ng-updates 47 k Transaction Summary ============================================================================================================================================ Upgrade 5 Packages Total download size: 5.2 M Is this ok [y/d/N]: y Downloading packages: Delta RPMs disabled because /usr/bin/applydeltarpm not installed. (1/5): xen-dom0-tools-4.17.6-9.3.1.xcpng8.3.x86_64.rpm | 2.0 MB 00:00:00 (2/5): xen-dom0-libs-4.17.6-9.3.1.xcpng8.3.x86_64.rpm | 704 kB 00:00:00 (3/5): xen-libs-4.17.6-9.3.1.xcpng8.3.x86_64.rpm | 66 kB 00:00:00 (4/5): xen-hypervisor-4.17.6-9.3.1.xcpng8.3.x86_64.rpm | 2.4 MB 00:00:00 (5/5): xen-tools-4.17.6-9.3.1.xcpng8.3.x86_64.rpm | 47 kB 00:00:00 -------------------------------------------------------------------------------------------------------------------------------------------- Total 2.9 MB/s | 5.2 MB 00:00:01 Running transaction check Running transaction test Transaction test succeeded Running transaction Updating : xen-libs-4.17.6-9.3.1.xcpng8.3.x86_64 1/10 Updating : xen-hypervisor-4.17.6-9.3.1.xcpng8.3.x86_64 2/10 Updating : xen-dom0-libs-4.17.6-9.3.1.xcpng8.3.x86_64 3/10 Updating : xen-tools-4.17.6-9.3.1.xcpng8.3.x86_64 4/10 Updating : xen-dom0-tools-4.17.6-9.3.1.xcpng8.3.x86_64 5/10 Cleanup : xen-dom0-tools-4.17.6-9.3.xcpng8.3.x86_64 6/10 Cleanup : xen-tools-4.17.6-9.3.xcpng8.3.x86_64 7/10 Cleanup : xen-dom0-libs-4.17.6-9.3.xcpng8.3.x86_64 8/10 Cleanup : xen-hypervisor-4.17.6-9.3.xcpng8.3.x86_64 9/10 Cleanup : xen-libs-4.17.6-9.3.xcpng8.3.x86_64 10/10 Verifying : xen-dom0-tools-4.17.6-9.3.1.xcpng8.3.x86_64 1/10 Verifying : xen-dom0-libs-4.17.6-9.3.1.xcpng8.3.x86_64 2/10 Verifying : xen-hypervisor-4.17.6-9.3.1.xcpng8.3.x86_64 3/10 Verifying : xen-libs-4.17.6-9.3.1.xcpng8.3.x86_64 4/10 Verifying : xen-tools-4.17.6-9.3.1.xcpng8.3.x86_64 5/10 Verifying : xen-libs-4.17.6-9.3.xcpng8.3.x86_64 6/10 Verifying : xen-dom0-tools-4.17.6-9.3.xcpng8.3.x86_64 7/10 Verifying : xen-hypervisor-4.17.6-9.3.xcpng8.3.x86_64 8/10 Verifying : xen-tools-4.17.6-9.3.xcpng8.3.x86_64 9/10 Verifying : xen-dom0-libs-4.17.6-9.3.xcpng8.3.x86_64 10/10 Updated: xen-dom0-libs.x86_64 0:4.17.6-9.3.1.xcpng8.3 xen-dom0-tools.x86_64 0:4.17.6-9.3.1.xcpng8.3 xen-hypervisor.x86_64 0:4.17.6-9.3.1.xcpng8.3 xen-libs.x86_64 0:4.17.6-9.3.1.xcpng8.3 xen-tools.x86_64 0:4.17.6-9.3.1.xcpng8.3 -
RE: XCP-ng 8.3 updates announcements and testing
Updates applied...
Updated: forkexecd.x86_64 0:26.1.11-1.2.xcpng8.3 kexec-tools.x86_64 1:2.0.15-21.1.xcpng8.3 message-switch.x86_64 0:26.1.11-1.2.xcpng8.3 qcow-stream-tool.x86_64 0:26.1.11-1.2.xcpng8.3 rrdd-plugins.x86_64 0:26.1.11-1.2.xcpng8.3 sm-cli.x86_64 0:26.1.11-1.2.xcpng8.3 squeezed.x86_64 0:26.1.11-1.2.xcpng8.3 varstored-guard.x86_64 0:26.1.11-1.2.xcpng8.3 vhd-tool.x86_64 0:26.1.11-1.2.xcpng8.3 wsproxy.x86_64 0:26.1.11-1.2.xcpng8.3 xapi-core.x86_64 0:26.1.11-1.2.xcpng8.3 xapi-nbd.x86_64 0:26.1.11-1.2.xcpng8.3 xapi-rrd2csv.x86_64 0:26.1.11-1.2.xcpng8.3 xapi-storage-script.x86_64 0:26.1.11-1.2.xcpng8.3 xapi-tests.x86_64 0:26.1.11-1.2.xcpng8.3 xapi-xe.x86_64 0:26.1.11-1.2.xcpng8.3 xcp-networkd.x86_64 0:26.1.11-1.2.xcpng8.3 xcp-rrdd.x86_64 0:26.1.11-1.2.xcpng8.3 xenopsd.x86_64 0:26.1.11-1.2.xcpng8.3 xenopsd-cli.x86_64 0:26.1.11-1.2.xcpng8.3 xenopsd-xc.x86_64 0:26.1.11-1.2.xcpng8.3 Complete!Will continue to test.
-
RE: XCP-ng 8.3 updates announcements and testing
@rzr Installed latest update and no issues to report. I dont hvae any 2tb+ drives in my vms. converting from vhd to qcow2 and backups all working.
-
RE: XCP-ng 8.3 updates announcements and testing
installed updates will report back.
Update - I had migrated vms back over to vhd prior to update release. I have migrated 2 vms back over to qcow2 and the initial backup ran successfull. Ran a second delta backup and that as well was successful with out issues. Backups happen very quickly now. But it appears the % and progress bar are working.
When CBT is enabled on the vm vdi. They show up as needing to be coalesced. VMs without CBT enabled the vdis are coalesced.
Will continue to monitor.
Once the coalesence hits 2 for the vm. The vm is skipped form future backups until cleared. (shutting down the vm will allow the coalescence to happen.
2026-04-23T19_52_34.694Z - backup NG.txt
-
RE: XCP-ng 8.3 updates announcements and testing
@olivierlambert Created new topic.
-
RE: XCP-ng 8.3 updates announcements and testing
Updated my to AMD Ryzen host in my home lab. No issues with update will monitor and report back any issues.
-
RE: XCP Pulse collects XCP-ng and Xen Orchestra logs
v0.6.0 — log collection is in. This was the piece the first post said was next, and it works end to end now.
A new Collect page runs a per-host collection as a background job: it pulls
logs.tgzand the XAPI audit trail from Xen Orchestra, keeps the raw copies, and produces a redacted copy of each. On my own XCP-ng 8.3 pool that came to 434 MiB for the bundle and 769 MiB for the audit trail, 2.3 GiB stored across the five files, with 2,542,805 values masked — almost all of them session tokens.The download is streamed a megabyte at a time and never held in memory, and every chunk is a cancellation point, so Cancel actually stops a transfer rather than waiting it out. A failed or cancelled download deletes its partial file instead of leaving a half-written bundle sitting there looking like a collection.
Both copies are kept and marked redacted — safe to send or raw — unmasked. Redaction is lossy, and the raw copy is the only thing that can answer "what did that used to say?" afterwards. Each collection writes the same redaction report the preview page produces, so you can see which rules fired — and which were switched off — before anything leaves the box. In the screenshot I had IPv4, MAC, UUIDs and hostnames turned off, and they show as off rather than as zero hits. That is deliberate: a partly-masked bundle should be obvious before you attach it to a ticket.
There is also a retention policy. The newest n collections are kept whatever their age, and only what is left is judged on age — a long gap in collecting can't empty the store. It shows you what a cleanup would delete and how much space that returns before you press the button.
Expect bugs. This is still very much a work in progress and it has only ever run against my own pool. If you try it in a different environment, assume things will break — please tell me what did. Known issues right now:
- The red "This connection uses a restricted account" warning on the Collect page shows for every connection, including an administrator one. It is a wrong condition in the template, not a real permission check — ignore it if your account is admin. The screenshot below has it, over a collection that succeeded.
- The Collect page says to expect "433 MB and 100 seconds per host". The 100 seconds is the download only; a full collection also fetches the audit trail and redacts both copies, which took 203 seconds on my pool. Budget three to four minutes.
Two more things worth flagging if you try this.
logs.tgzsends noContent-Length, so a reverse proxy that buffers will happily hand you a truncated archive with HTTP 200. Mine did. It now detects that and reports the bundle as cut short rather than as a protocol error, and repacks whatever did arrive instead of throwing the lot away. If you are behind Nginx Proxy Manager,proxy_buffering off;andproxy_max_temp_file_size 0;are what fixed the stall for me.The account requirement from the first post has not changed — the log download needs
export:logson host, and on the instance I measured that is only reachable via Administrator. Inventory still works fine on Read only.Next up: individual log categories pulled out of the cached bundle (~35 MB instead of 434 MiB), date ranges, and then findings.
https://github.com/acebmxer/xcp_pulse
-
RE: Veeam and XO backup CBT. How to avoid conflict?
I would advise not backing up the same vms with both XO and veeam. One or the other. No did not see the update yet. I will look and check.
Edit - thanks or pointing out the new version. I was still on 13.1.0.411. Downloading update now.
-
RE: Veeam and XO backup CBT. How to avoid conflict?
Hello if you have not seen this post - https://xcp-ng.org/forum/topic/12407/veeam-13.1-rocky9-linux-appliance-potential-data-loss-with-cbt-and-workers-with-expired-tokens Myself and another user reported issues with Veeam and CBT.
My latest update from Veeam was no eta on the next update release to fix the issues. That has been some time and there might be a eta. I have not followed back up as of yet.
On thing that seems to have helped was using Active Full backup opposed to Synthetic full backups.
-
RE: XCP-ng 8.3 updates announcements and testing
Last night I finished migrating to new to me cisco 25gb switch. Other changes I made was remove an ISCSI SR I was not utilizing and an NFS SR. Also migrated all vms to newly created QCOW2 NFS SR (in XO) and migrated all vms to the new SR. Checked that NBD and CBD were enabled in the backup job. I ran a full backup and it completed successfully.
Just to be sure I decided to re-install xcp-ng 8.3 on both host and re-apply the recent version of the updates. Ran delta backup and it passed.
I dont believe i missed anything in between last failed backup and issue i posted. Maybe I has having issues with the previous 10gb switch that were not visible with out taken deeper look?
If there is something specific you would like for me to check to test. But starting from clean slate / new switch seems to have helped?
-
RE: XCP-ng 8.3 updates announcements and testing
@anthoineb
Since I had to physical power cycle to clear the I/O block and recover the host, the live kernel state and any active blocked PIDs from the window of the deadlock were cleared upon reboot.
Checking the host right now, there are currently no processes sitting in an uninterruptible sleep (D) state, andtap-ctllist shows the standard operational mappings for the running VMs:# tap-ctl list 5175 0 0 vhd /var/run/sr-mount/4991d4aa-ed84-599b-7d19-97f2f943a366/8d3ce0d6-7d4d-40b0-a99f-09daab8d55e1.vhd 5720 1 0 vhd /var/run/sr-mount/4991d4aa-ed84-599b-7d19-97f2f943a366/1c200822-5a23-4afa-93cd-d0d89c076191.vhd 6941 2 0 vhd /var/run/sr-mount/4991d4aa-ed84-599b-7d19-97f2f943a366/0fac203e-4740-4f95-a78c-a3630e591e76.vhd # ps aux | awk '$8 ~ /D/' (Returned empty)Got it regarding the lock retry behavior in SMlog—thanks for clarifying that component. I am pulling the full un-truncated kern.log.1 from yesterday to add to the Google Drive folder so you can inspect the historical kernel call traces right when the backup stream hit the wall.
I have uploaded the raw
kern.log.1file directly to the shared folder.Let me know if you want to add the exact file name context anywhere else in the message.
-
RE: Node.js October 21, 2026 Security Releases
If you are using my installer script (https://github.com/acebmxer/install_xen_orchestra), there are two quick ways to verify the active Node.js version. @poddingue can you confirm this is correct?
1. During the Update/Install Process
The script explicitly pulls the active environment version and prints it out against your NODE_VERSION target in the logs:❯ node -v v24.22.1 [INFO] Node.js v24.22.1 satisfies configured version 24 — no runtime change needed [INFO] Installing Node.js 24... [INFO] Node.js 24 requirement satisfied (installed: v24.22.1)2. Verifying the Live Service Runtime
To be absolutely certain that the running systemd daemon is executing the correct binary instance after a restart, you can check the status of the xo-server unit:sudo systemctl status xo-server.serviceLook at the CGroup line in the output. It maps directly to the active path and flags (such as the heap memory allocations set by the script):
CGroup: /system.slice/xo-server.service └─18540 /usr/bin/node --max-old-space-size=5410 /opt/xen-orchestra/packages/xo-server/dist/cli.mjsYou can then run
/usr/bin/node -v(or whatever path is reflected there) to double-check that the active service binary is indeed on the patched release line (v24.22.1, v22.23.4, etc.). -
RE: XCP-ng 8.3 updates announcements and testing
Here are the extracted Xen hypervisor, Dom0 kernel, and toolstack/storage manager logs tracking the exact window of the NFS storage deadlock on Oct 27 between 13:00 and 15:00.
During this window,
xe task-listwas completely blank, and user VMs went into an uninterruptible B H state (turning into zombieD P Hdomains upon anxl destroyattempt). Physical hardware interfaces showed zero errors or discards via ethtool.Looking closely at
crash_window_SMlog.log, there is a clear locking deadlock right at the start of the backup run (13:00:38):
"Failed to lock /var/lock/sm/96fd7d5a-1985-80be-5776-6ace7f651a41/sr on first attempt, blocked by PID 86371"It looks like the parallel multi-stream VHD storage exports/NBD operations lock-contended the SR control handles so badly that the underlying sm/blktap layer deadlocked entirely.
I have attached the full log bundle containing:
xen_hypervisor.log(Xen ring buffer /xl dmesg)crash_window_kernel.log(Dom0 kernel events from/var/log/kern.log)crash_window_SMlog.log(Storage manager tracks from/var/log/SMlog.1)xapi_crash.log(Toolstack logs from/var/log/xensource.log.1)
https://drive.google.com/drive/folders/1uCnWXArfgyvS1gPl3mViUl8G1-DBOGzD?usp=sharing - due to file size and type i could not upload here. So i posted it on my google drive.
-
RE: XCP-ng 8.3 updates announcements and testing
of course i just downgraded again prior to this release... Sorry for the post. This was assisted with AI. I was also trying to do this while at work
. I tried to verify this was not caused be my actions or configuration. If this is the results of upgrading and downgrading then everyelse use this a learning point.[13:10 xcp-ng-disjqdnc ~]# yum history Loaded plugins: fastestmirror ID | Command line | Date and time | Action(s) | Altered ------------------------------------------------------------------------------- 16 | update --enablerepo=xcp- | 2026-10-27 13:04 | Update | 35 EE 15 | history undo 14 | 2026-10-27 10:37 | Downgrade | 35 EE 14 | update --enablerepo=xcp- | 2026-10-22 19:00 | Update | 35 EE 13 | update --disablerepo=* - | 2026-10-22 15:40 | Update | 1 12 | history undo 11 | 2026-10-22 13:37 | Downgrade | 35 EE 11 | update --enablerepo=xcp- | 2026-10-22 05:58 | Update | 35 EE 10 | update --disablerepo=* - | 2026-10-13 13:13 | Update | 6 9 | update --disablerepo=* - | 2026-10-05 15:04 | Update | 20 8 | update --enablerepo=xcp- | 2026-10-01 09:12 | Update | 45 EE 7 | update --disablerepo=* - | 2026-09-08 16:06 | Update | 6 6 | update --enablerepo=xcp- | 2026-08-26 08:39 | Update | 23 EE 5 | update --enablerepo=xcp- | 2026-08-14 13:23 | I, U | 53 EE 4 | update | 2026-07-28 10:46 | Update | 5 3 | update --enablerepo=xcp- | 2026-07-10 11:27 | Update | 23 EE 2 | install -y /root/twinsto | 2026-07-05 20:16 | Install | 12 1 | update --disablerepo=* - | 2026-07-05 01:56 | I, O, U | 138 EEhistory list
updates installed no issues. I did a full backup job prior to new updates. after updates I did a delta backup. (vms are in VHD format)
migrated VMS back to QCOW2 and ran another backup. Because of migration this was a full backup..
Ran into a massive storage deadlock testing this batch of candidates on my NFS setups with Mellanox ConnectX links.
Here is the exact timeline and raw outputs of what went down:
- Clean baseline: Rolled back previous stuff via
yum history undoso the host was at a completely clean slate first. - Pre-test: Ran a full backup on standard VHD layout on the stable build. Zero issues, finished perfectly fine.
- The update: Upgraded to the testing candidate repo (ID 16 in my history output above).
- The trigger: Cleared a delta backup right after, then kicked off a full backup job. No other out-of-band tasks or live migrations were happening.
The Breakdown:
Mid-way through that full VHD backup, the entire storage layer completely locked up.- Toolstack went blind:
xe task-listwas completely blank. The host totally lost track of the job it was supposed to be running. - VMs deadlocked: Every user VM instantly frozen into a hard Blocked/Halted (
B H) state. Trying a low-levelxl destroyjust turned them into permanent un-killable zombie domains (D P H).
[13:33 xcp-ng-rngyaiub ~]# xl destroy 1 [13:33 xcp-ng-rngyaiub ~]# list_domains id | uuid | state 0 | 2083b5bd-7878-4598-960f-bb425814d338 | R 1 | 49f51614-c105-4fea-3103-566613ec79f2 | D P H 2 | dcbfaff1-d782-b42b-6eed-3d6b6d1ca032 | D P H 3 | 8cc17a78-ef65-1c06-4ac1-8e56b609d714 | D P H 4 | 2f724b50-5b16-9975-839b-fd85dd8ed065 | D P HHardware / Config Diagnostics:
Before pointing fingers at the candidate code, I checked if my Mellanox links or the network switch choked under the backup stream load. Ranethtoolimmediately following recovery and the physical interfaces are pristine:[14:16 xcp-ng-disjqdnc ~]# ethtool -S eth1 | grep -E "discard|drop|filter|error" rx_xdp_drop: 0 tx_queue_dropped: 0 rx_oversize_pkts_sw_drop: 0 rx_pet_hdr_lookup_drop: 0 rx_pet_mdata_lookup_drop: 0 rx_xsk_xdp_drop: 0 rx_xsk_oversize_pkts_sw_drop: 0 rx_crc_errors_phy: 0 rx_in_range_len_errors_phy: 0 rx_discards_phy: 0 tx_discards_phy: 0 tx_errors_phy: 0 rx_prio0_discards: 0 rx_prio1_discards: 0 rx_prio2_discards: 0 rx_prio3_discards: 0 rx_prio4_discards: 0 rx_prio5_discards: 0 rx_prio6_discards: 0 rx_prio7_discards: 0 tx_pause_storm_error_events: 0 [14:18 xcp-ng-disjqdnc ~]# ethtool -k eth1 | grep -i vlan rx-vlan-offload: on tx-vlan-offload: on rx-vlan-filter: on vlan-challenged: off [fixed] tx-vlan-stag-hw-insert: on rx-vlan-stag-hw-parse: off [fixed] rx-vlan-stag-filter: on [fixed]Conclusion:
Network layout config problems, buffer overflows, or silent packet drops are 100% ruled out here (all hardware discards are flat zero).This wasn't a user mistake or an accidental configuration mismatch. The new
smorblktapcomponents hit a deep kernel lockup handling the multi-stream VHD storage exports. The file locks deadlocked the kernel handles so badly that the hosts ignored standard and low-level CLI commands entirely, forcing a hard out-of-band physical power cycle of the XCP-ng hosts and the TrueNAS storage server just to clear the uninterruptible I/O sleep queue.I haven't touched a thing since getting the hardware back up and verifying what choked. The system is sitting exactly as it is right now. Let me know what specific debugging paths you want me to look at or what logs you need from that window to trace this down.
- Clean baseline: Rolled back previous stuff via
-
RE: Missing vdi which is a base for a delta
Are you using XOA or XO from sources? If the later what Commit are you on? Did you install the recent beta updates for your hosts?
Can you post the log of the the failed backups.
-
RE: XCP-ng 8.3 updates announcements and testing
I reinstalled the updates, and confirm backups work with NBD disablled in backup job. - I missed the part about NBD in the notes..
However the task stay at 0% while i can see traffic on my trunas..
-
RE: XCP-ng 8.3 updates announcements and testing
@acebmxer said:
(...)
yum history undo <ID> --enablerepo=xcp-ng-testing
(...)Your're lucky ! this is a risky operation we don't recommend to downgrade because some packages like xapi are not handling this properly, prefer other workarounds if there are any (like disabling nbd until @storage team suggest a better option)
Let me thank you again @flakpyro for this regression report it is very valuable to us,
I didn't run the commands I stated. As I was asking first.. I did the command @flakpryo
Of course this is was before i saw your post. As this is the home lab i am fine with if it blows up. but for others this is good to know.