<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title><![CDATA[Compute]]></title><description><![CDATA[All Xen related stuff]]></description><link>https://xcp-ng.org/forum/category/15</link><generator>RSS for Node</generator><lastBuildDate>Sun, 06 Sep 2026 21:11:35 GMT</lastBuildDate><atom:link href="https://xcp-ng.org/forum/category/15.rss" rel="self" type="application/rss+xml"/><pubDate>Thu, 03 Sep 2026 11:17:10 GMT</pubDate><ttl>60</ttl><item><title><![CDATA[Why doesn't /var/log/messages have the 100 MiB rsyslog trigger?]]></title><description><![CDATA[On one machine in my lab, /etc/rsyslog.d/xenserver.conf defines 17 outchannels, every one of them at 104857600 bytes, and /var/log/messages isn't one of them; it's written by the stock *.info;mail.none;authpriv.none;cron.none line in /etc/rsyslog.conf and rotated by /etc/logrotate.d/syslog, so nightly and with no size trigger.
The docs at https://docs.xcp-ng.org/guides/logs#rsyslog describe the 100 MiB rule but don't list which files it actually covers, which is probably why this is hard to work out without reading the config the way you did.
Whether messages can realistically outrun a nightly rotation I don't know, and I'd be guessing if I said either way; the one thing in your favour is that /var/log is its own filesystem, 3.9 GB on the box I looked at (small lab machine, I haven't searched in the code, so I don't know where that size is decided), so it can't take the rest of dom0 with it. 
Whether that omission is deliberate or just inherited (or even something fancier) is really a question for whoever owns that file, so it might be worth a mention to @Team-OS-Platform-Release.
]]></description><link>https://xcp-ng.org/forum/topic/12452/why-doesn-t-var-log-messages-have-the-100-mib-rsyslog-trigger</link><guid isPermaLink="true">https://xcp-ng.org/forum/topic/12452/why-doesn-t-var-log-messages-have-the-100-mib-rsyslog-trigger</guid><dc:creator><![CDATA[poddingue]]></dc:creator><pubDate>Thu, 03 Sep 2026 11:17:10 GMT</pubDate></item><item><title><![CDATA[i915 pass-through and Linux Mint - xcp-ng 8.3]]></title><description><![CDATA[Intel needs some special handling to support physical displays with PCI Passthrough; I don't know much of the details, but on "recent" machines, some bits are missing according to :
https://lore.kernel.org/all/20260802050824.10554-1-brchuckz@aol.com/
]]></description><link>https://xcp-ng.org/forum/topic/12422/i915-pass-through-and-linux-mint-xcp-ng-8.3</link><guid isPermaLink="true">https://xcp-ng.org/forum/topic/12422/i915-pass-through-and-linux-mint-xcp-ng-8.3</guid><dc:creator><![CDATA[TeddyAstie]]></dc:creator><pubDate>Wed, 19 Aug 2026 00:13:07 GMT</pubDate></item><item><title><![CDATA[Ubuntu cloud images on XCP-ng 8.3 UEFI: ~15s per secondary vCPU at boot, caused by console=ttyS0]]></title><description><![CDATA[@poddingue Thanks for running the -31 numbers — good to have it confirmed that the ttyS0 removal stays worth ~3-4s even with the clock fixed. Agreed on not rushing -proposed to production; we'll pick up -31 when it promotes and keep the cloud-init tweak permanently.
]]></description><link>https://xcp-ng.org/forum/topic/12419/ubuntu-cloud-images-on-xcp-ng-8.3-uefi-15s-per-secondary-vcpu-at-boot-caused-by-console-ttys0</link><guid isPermaLink="true">https://xcp-ng.org/forum/topic/12419/ubuntu-cloud-images-on-xcp-ng-8.3-uefi-15s-per-secondary-vcpu-at-boot-caused-by-console-ttys0</guid><dc:creator><![CDATA[dvinni]]></dc:creator><pubDate>Mon, 17 Aug 2026 19:17:06 GMT</pubDate></item><item><title><![CDATA[Windows guests destroyed by PoD exhaustion with Citrix tools — XCP-ng tools fix it, but XO gives no warning either way]]></title><description><![CDATA[Filed both XO related issues:

Memory visibility at VM creation: https://github.com/vatesfr/xen-orchestra/issues/10225
domain_crash invisible in XO: https://github.com/vatesfr/xen-orchestra/issues/10226

Linking to this thread as promised earlier, thanks all.  Hope this helps someone out.
]]></description><link>https://xcp-ng.org/forum/topic/12399/windows-guests-destroyed-by-pod-exhaustion-with-citrix-tools-xcp-ng-tools-fix-it-but-xo-gives-no-warning-either-way</link><guid isPermaLink="true">https://xcp-ng.org/forum/topic/12399/windows-guests-destroyed-by-pod-exhaustion-with-citrix-tools-xcp-ng-tools-fix-it-but-xo-gives-no-warning-either-way</guid><dc:creator><![CDATA[kagbasi-wgsdac]]></dc:creator><pubDate>Mon, 03 Aug 2026 09:17:14 GMT</pubDate></item><item><title><![CDATA[Intermittent Xen blkfront I/O stalls: all guest tags busy while tapdisk reports zero outstanding requests]]></title><description><![CDATA[@mike.potapov Can you upgrade to the latest blktap-3.55.5-9.3.xcpng8.3 to check is the issue is still there?
]]></description><link>https://xcp-ng.org/forum/topic/12362/intermittent-xen-blkfront-i-o-stalls-all-guest-tags-busy-while-tapdisk-reports-zero-outstanding-requests</link><guid isPermaLink="true">https://xcp-ng.org/forum/topic/12362/intermittent-xen-blkfront-i-o-stalls-all-guest-tags-busy-while-tapdisk-reports-zero-outstanding-requests</guid><dc:creator><![CDATA[anthoineb]]></dc:creator><pubDate>Wed, 15 Jul 2026 09:17:19 GMT</pubDate></item><item><title><![CDATA[Windows Server 2025 VM randomly freezes/hangs (loss of VNC + RDP + console) on XCP-ng — reboot required]]></title><link>https://xcp-ng.org/forum/topic/12360/windows-server-2025-vm-randomly-freezes-hangs-loss-of-vnc-rdp-console-on-xcp-ng-reboot-required</link><guid isPermaLink="true">https://xcp-ng.org/forum/topic/12360/windows-server-2025-vm-randomly-freezes-hangs-loss-of-vnc-rdp-console-on-xcp-ng-reboot-required</guid><pubDate>Wed, 15 Jul 2026 08:11:47 GMT</pubDate></item><item><title><![CDATA[RDNA 4 GPU Passthrough]]></title><description><![CDATA[@ravenet Sure, gave that a whirl and no change, though I did notice some nvtop weirdness as it would show some load, but most of the wait time there was actually no load on the GPUs instead of the constant load matching the model being loaded. For some historical context ARI support was initially disabled in the bios when I started this thread. That was on the list of things I enabled when I started seeing some success with ollama (something in the changes since has broken ollama now too, but there was at least some forward progress after enabling). dmesg output overall looked the same, but I did see this output on the console (and in dmesg) that seemed interesting. Not 100% sure at this point if this was in the previous dmesg outputs or not, but may be worth sharing. EDIT: looks like this may actually be new... I looked back through the past dm dmesg outputs and I did not see this output.
[  108.547683] amdgpu 0000:00:09.0: MES(0) failed to respond to msg=REMOVE_QUEUE
[  108.547729] amdgpu 0000:00:09.0: failed to remove hardware queue from MES, doorbell=0x1202
[  108.547746] amdgpu 0000:00:09.0: MES might be in unrecoverable state, issue a GPU reset
[  108.547774] amdgpu 0000:00:09.0: Failed to evict queue 2
[  108.547789] amdgpu 0000:00:09.0: Failed to evict process queues
[  108.547803] amdgpu: Failed to quiesce KFD
[  108.547870] amdgpu 0000:00:09.0: GPU reset begin!. Source:  3
[  109.656850] amdgpu 0000:00:09.0: Failed to remove queue 0
[  109.657324] amdgpu 0000:00:09.0: Dumping IP State
[  109.756265] amdgpu 0000:00:09.0: Dumping IP State Completed
[  112.047695] amdgpu 0000:00:09.0: MODE1 reset
[  112.047797] amdgpu 0000:00:09.0: GPU mode1 reset
[  112.054505] amdgpu 0000:00:09.0: GPU smu mode1 reset
[  113.075393] amdgpu 0000:00:09.0: GPU reset succeeded, trying to resume
[  113.090354] amdgpu 0000:00:09.0: [drm] PCIE GART of 512M enabled (table at 0x00000087D6B00000).
[  113.092905] amdgpu 0000:00:09.0: [drm] AMDGPU device coredump file has been created
[  113.092913] amdgpu 0000:00:09.0: [drm] Check your /sys/class/drm/card1/device/devcoredump/data
[  113.092917] amdgpu 0000:00:09.0: VRAM is lost due to GPU reset!
[  113.092921] amdgpu 0000:00:09.0: PSP is resuming...
[  114.997591] amdgpu 0000:00:09.0: GECC is disabled, set amdgpu_ras_enable=1 to enable GECC in next boot cycle if needed
[  115.091125] amdgpu 0000:00:09.0: RAP: optional rap ta ucode is not available
[  115.091130] amdgpu 0000:00:09.0: SECUREDISPLAY: optional securedisplay ta ucode is not available
[  115.091134] amdgpu 0000:00:09.0: SMU is resuming...
[  115.091375] amdgpu 0000:00:09.0: smu driver if version = 0x0000002e, smu fw if version = 0x00000033, smu fw program = 0, smu fw version = 0x00684c00 (104.76.0)
[  115.432371] amdgpu 0000:00:09.0: SMU is resumed successfully!
[  115.445556] amdgpu 0000:00:09.0: program CP_MES_CNTL : 0x4000000
[  115.445731] amdgpu 0000:00:09.0: program CP_MES_CNTL : 0xc000000
[  115.750240] amdgpu 0000:00:09.0: [drm] DMUB hardware initialized: version=0x0A000800

As an update for other things I have tried, in order to eliminate hardware issues, or bios settings I tried installing proxmox and spinning up a VM there with both GPUs passed through and it worked just fine... With that feedback I did a fresh install of XCP-NG 8.3 and spun up a fresh VM using the same steps as I used on proxmox and still no dice. This leads me to believe the issue is somewhere in the XCP-NG passthrough stack with my specific hardware...
]]></description><link>https://xcp-ng.org/forum/topic/12345/rdna-4-gpu-passthrough</link><guid isPermaLink="true">https://xcp-ng.org/forum/topic/12345/rdna-4-gpu-passthrough</guid><dc:creator><![CDATA[PessimistTech]]></dc:creator><pubDate>Sun, 05 Jul 2026 01:42:01 GMT</pubDate></item><item><title><![CDATA[PCIe Pass-through  lanes and lane performance]]></title><description><![CDATA[@dkidd255 @jamesg
I didn't forgot about it, but I still don't have access to relevant hardware (for reasons outside of my control).
In the meantime, if that happens to be related, can you try the patch that allows disabling hvm-pirq (this is going to be globally available soon) ?
]]></description><link>https://xcp-ng.org/forum/topic/12316/pcie-pass-through-lanes-and-lane-performance</link><guid isPermaLink="true">https://xcp-ng.org/forum/topic/12316/pcie-pass-through-lanes-and-lane-performance</guid><dc:creator><![CDATA[TeddyAstie]]></dc:creator><pubDate>Thu, 25 Jun 2026 23:54:48 GMT</pubDate></item><item><title><![CDATA[Slow response between XCP-NG and cloud stack syncing]]></title><description><![CDATA[Hi,
XCP-ng got an event system that will propagate things like this instantly, at least that's the way it works normally 

Do you have the same behaviour in Xen Orchestra?
Have you reported the issue to CloudStack?
If you have an XCP-ng support subscription, you can also open a ticket so we can take a look on XCP-ng status to catch any obvious issue.

]]></description><link>https://xcp-ng.org/forum/topic/12285/slow-response-between-xcp-ng-and-cloud-stack-syncing</link><guid isPermaLink="true">https://xcp-ng.org/forum/topic/12285/slow-response-between-xcp-ng-and-cloud-stack-syncing</guid><dc:creator><![CDATA[olivierlambert]]></dc:creator><pubDate>Tue, 16 Jun 2026 04:41:18 GMT</pubDate></item><item><title><![CDATA[Slow boot on rocky linux 10 latest kernel]]></title><description><![CDATA[Thanks for actually booting one, that's the bit I skipped. 
-84s versus -10s without console=ttyS0 matches the Ubuntu ratio, and it's the first EL10 number anyone has measured rather than read from the source. 
That settles the question I left open. A real-world measurement is vastly better than a source-code read, right?
Thanks for the backport request, too. Since CentOS Stream sits upstream of RHEL and Rocky, if the backport lands there, it should be the earliest signal that the rest of the family will follow.  
]]></description><link>https://xcp-ng.org/forum/topic/12260/slow-boot-on-rocky-linux-10-latest-kernel</link><guid isPermaLink="true">https://xcp-ng.org/forum/topic/12260/slow-boot-on-rocky-linux-10-latest-kernel</guid><dc:creator><![CDATA[poddingue]]></dc:creator><pubDate>Fri, 05 Jun 2026 15:20:37 GMT</pubDate></item><item><title><![CDATA[xe sr-create ignores other-config:auto-scan=true during SR creation]]></title><description><![CDATA[@psafont Thanks for the quick response and clarification. I appreciate you opening a work item for this. Looking forward to seeing this improvement in a future release.
]]></description><link>https://xcp-ng.org/forum/topic/12248/xe-sr-create-ignores-other-config-auto-scan-true-during-sr-creation</link><guid isPermaLink="true">https://xcp-ng.org/forum/topic/12248/xe-sr-create-ignores-other-config-auto-scan-true-during-sr-creation</guid><dc:creator><![CDATA[mdm]]></dc:creator><pubDate>Fri, 29 May 2026 13:29:25 GMT</pubDate></item><item><title><![CDATA[XAPI sr-create ignores name-description parameter]]></title><description><![CDATA[@psafont Thank you for the quick response.
I also found a similar issue: the other-config:auto-scan=true parameter is not being applied during xe sr-create either. As with the name-description parameter, the workaround is to add it separately afterwards using xe sr-param-add.
]]></description><link>https://xcp-ng.org/forum/topic/12213/xapi-sr-create-ignores-name-description-parameter</link><guid isPermaLink="true">https://xcp-ng.org/forum/topic/12213/xapi-sr-create-ignores-name-description-parameter</guid><dc:creator><![CDATA[mdm]]></dc:creator><pubDate>Wed, 13 May 2026 11:52:13 GMT</pubDate></item><item><title><![CDATA[Date format on web interface: Only US format available?]]></title><description><![CDATA[@acomav We will actually propose to change the date and time format in XO6 settings, so you would be able to choose between :

YYYY-MM-DD
MM/DD/YYYY
DD/MM/YYYY
and  12h or 24h time format.
Hopefully in one of the next 3 months !
I hope that will answer your need, otherwise let me know !

]]></description><link>https://xcp-ng.org/forum/topic/12110/date-format-on-web-interface-only-us-format-available</link><guid isPermaLink="true">https://xcp-ng.org/forum/topic/12110/date-format-on-web-interface-only-us-format-available</guid><dc:creator><![CDATA[julienXOvates]]></dc:creator><pubDate>Thu, 30 Apr 2026 00:12:41 GMT</pubDate></item><item><title><![CDATA[VM Migration | PIF is not attached]]></title><description><![CDATA[The "PIF is not attached" usually means the network interface selected as the migration network isn't currently active on the target host.
It can happen after upgrades if the host hasn't been fully rebooted.
Worth checking whether a reboot of both hosts changes anything, and running xe pif-list to see whether that specific PIF shows currently-attached: true on the target. 
If the PIF looks attached in xe but migration still fails, might be worth a ping to Team-XAPI-Network. 
]]></description><link>https://xcp-ng.org/forum/topic/12044/vm-migration-pif-is-not-attached</link><guid isPermaLink="true">https://xcp-ng.org/forum/topic/12044/vm-migration-pif-is-not-attached</guid><dc:creator><![CDATA[poddingue]]></dc:creator><pubDate>Wed, 01 Apr 2026 16:02:20 GMT</pubDate></item><item><title><![CDATA[Application on VM causing BSOD]]></title><description><![CDATA[@TeddyAstie
Attached is the output you requested
xen-cpuid -p.txt
]]></description><link>https://xcp-ng.org/forum/topic/12008/application-on-vm-causing-bsod</link><guid isPermaLink="true">https://xcp-ng.org/forum/topic/12008/application-on-vm-causing-bsod</guid><dc:creator><![CDATA[tsukraw]]></dc:creator><pubDate>Wed, 25 Mar 2026 18:02:26 GMT</pubDate></item><item><title><![CDATA[COM Port Windows guest VM to network]]></title><description><![CDATA[@TeddyAstie That's more like it.  I'm not finding the com2tcp though.  I at least have something to search for.
Once configured, is this persistent or do I need to create some sort of start up script that runs/loads a config on machine boot?
Thanks!!
]]></description><link>https://xcp-ng.org/forum/topic/11977/com-port-windows-guest-vm-to-network</link><guid isPermaLink="true">https://xcp-ng.org/forum/topic/11977/com-port-windows-guest-vm-to-network</guid><dc:creator><![CDATA[JamesG]]></dc:creator><pubDate>Wed, 18 Mar 2026 20:12:41 GMT</pubDate></item><item><title><![CDATA[Nested Virtualization in xcp-ng]]></title><description><![CDATA[@abudef Some quotes from the documentation to clarify the situation: https://docs.xcp-ng.org/compute/#-nested-virtualization
]]></description><link>https://xcp-ng.org/forum/topic/11963/nested-virtualization-in-xcp-ng</link><guid isPermaLink="true">https://xcp-ng.org/forum/topic/11963/nested-virtualization-in-xcp-ng</guid><dc:creator><![CDATA[yannsionneau]]></dc:creator><pubDate>Fri, 13 Mar 2026 06:47:25 GMT</pubDate></item><item><title><![CDATA[Memory Ballooning (DMC) broken since XCP-ng 8.3 January 2026 patches]]></title><description><![CDATA[I can confirm that when using Citrix/Xenserver guest utilities version 8.4 (https://github.com/xenserver/xe-guest-utilities/releases/tag/v8.4.0) memory ballooning / DMC is working fine.
After live migration the RAM of the linux guest is expanded to dynamic_max again.
So this issue was in fact caused by Rust based xen-guest-agent.
For now I'll keep using Citrix/Xenserver guest utilities on my Linux guests until the feature is implemented in Vates rust-based guest utilities.
Best regards
]]></description><link>https://xcp-ng.org/forum/topic/11955/memory-ballooning-dmc-broken-since-xcp-ng-8.3-january-2026-patches</link><guid isPermaLink="true">https://xcp-ng.org/forum/topic/11955/memory-ballooning-dmc-broken-since-xcp-ng-8.3-january-2026-patches</guid><dc:creator><![CDATA[MajorP93]]></dc:creator><pubDate>Wed, 11 Mar 2026 10:42:54 GMT</pubDate></item><item><title><![CDATA[OpenBSD UEFI install/boot panics.]]></title><description><![CDATA[Having help from OpenBSD side could be the way to go.
Please forward your report to bugs@openbsd.org (with a link to this post too)
For the record, I am able to reproduce it too (on XCP-ng 8.3 too, using OpenBSD -current).
]]></description><link>https://xcp-ng.org/forum/topic/11953/openbsd-uefi-install-boot-panics.</link><guid isPermaLink="true">https://xcp-ng.org/forum/topic/11953/openbsd-uefi-install-boot-panics.</guid><dc:creator><![CDATA[semarie]]></dc:creator><pubDate>Wed, 11 Mar 2026 04:48:23 GMT</pubDate></item><item><title><![CDATA[update: vGPU w NVIDIA Tesla P4]]></title><description><![CDATA[Thank you all for information. I will try to virtualize GPU to Windows VMs.
]]></description><link>https://xcp-ng.org/forum/topic/11869/update-vgpu-w-nvidia-tesla-p4</link><guid isPermaLink="true">https://xcp-ng.org/forum/topic/11869/update-vgpu-w-nvidia-tesla-p4</guid><dc:creator><![CDATA[Aleksander]]></dc:creator><pubDate>Sun, 15 Feb 2026 02:11:51 GMT</pubDate></item><item><title><![CDATA[XCP 8.3: wsproxy and other swap... why?]]></title><description><![CDATA[I made a list of processes with a small bash script that I am attaching here
[image: 1769612600385-screenshot-2026-01-28-alle-16.01.53.png]
]]></description><link>https://xcp-ng.org/forum/topic/11808/xcp-8.3-wsproxy-and-other-swap...-why</link><guid isPermaLink="true">https://xcp-ng.org/forum/topic/11808/xcp-8.3-wsproxy-and-other-swap...-why</guid><dc:creator><![CDATA[rvl]]></dc:creator><pubDate>Wed, 28 Jan 2026 14:55:11 GMT</pubDate></item><item><title><![CDATA[TrueNAS VM failing to start]]></title><description><![CDATA[@tuxen Doing some research, it doesn't look like the Xeon's I have are affected.
But I'm willing to try the next time I need to reboot.  Will report back after that.
]]></description><link>https://xcp-ng.org/forum/topic/11763/truenas-vm-failing-to-start</link><guid isPermaLink="true">https://xcp-ng.org/forum/topic/11763/truenas-vm-failing-to-start</guid><dc:creator><![CDATA[EddieA]]></dc:creator><pubDate>Tue, 13 Jan 2026 02:29:39 GMT</pubDate></item><item><title><![CDATA[Pinning CPUs to dom0 - Does it really make a difference?]]></title><description><![CDATA[@hitechhillbilly no it doesn't, it just ensures the N-th vCPU  of Dom0 only runs on N-th pCPU of the machine.
Not sure about the practical impact of it, in the past it has been used for getting meaningful CPU temperatures from coretemp (with physical core matching virtual one), but that doesn't work anymore since Xen filters MSR accesses (including Dom0).
]]></description><link>https://xcp-ng.org/forum/topic/11691/pinning-cpus-to-dom0-does-it-really-make-a-difference</link><guid isPermaLink="true">https://xcp-ng.org/forum/topic/11691/pinning-cpus-to-dom0-does-it-really-make-a-difference</guid><dc:creator><![CDATA[TeddyAstie]]></dc:creator><pubDate>Wed, 17 Dec 2025 16:31:11 GMT</pubDate></item><item><title><![CDATA[Unable to MIgrate VDI when host is low on free memory]]></title><description><![CDATA[I just learned something new, thats awesome 
]]></description><link>https://xcp-ng.org/forum/topic/11688/unable-to-migrate-vdi-when-host-is-low-on-free-memory</link><guid isPermaLink="true">https://xcp-ng.org/forum/topic/11688/unable-to-migrate-vdi-when-host-is-low-on-free-memory</guid><dc:creator><![CDATA[nikade]]></dc:creator><pubDate>Tue, 16 Dec 2025 15:48:30 GMT</pubDate></item><item><title><![CDATA[Install mono on XCP-ng]]></title><description><![CDATA[@isdpcman-0 said in Install mono on XCP-ng:

Our RMM tools will run on CentOS but fail to install because they are looking for mono to be on the system. How can I install Mono on an XCP-ng host so we can install our monitoring/management tools?
Reply

I think it is advised to consider hosts as appliances and not install any external packages (repos are disabled for that purpose, that's probably your issue for installing anything)
even in case of clusters of many hosts in a pool, you should deploy same packages on all hosts to expect compliancy between hosts...
better use SNMP to monitor you hosts ? or standard installed packages ?
]]></description><link>https://xcp-ng.org/forum/topic/11642/install-mono-on-xcp-ng</link><guid isPermaLink="true">https://xcp-ng.org/forum/topic/11642/install-mono-on-xcp-ng</guid><dc:creator><![CDATA[Pilow]]></dc:creator><pubDate>Thu, 04 Dec 2025 15:43:34 GMT</pubDate></item></channel></rss>