<?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[XCP-ng]]></title><description><![CDATA[Everything related to the virtualization platform]]></description><link>https://xcp-ng.org/forum/category/19</link><generator>RSS for Node</generator><lastBuildDate>Sat, 12 Sep 2026 17:00:52 GMT</lastBuildDate><atom:link href="https://xcp-ng.org/forum/category/19.rss" rel="self" type="application/rss+xml"/><pubDate>Wed, 09 Sep 2026 08:25:04 GMT</pubDate><ttl>60</ttl><item><title><![CDATA[`/run/sr-mount` parent directory created 0700 on some hosts, 0755 on others]]></title><description><![CDATA[@Dan Hello,
So our investigation found that this change was introduced with commit https://github.com/xcp-ng/sm/commit/00637dd52e845d6016add9718fc9cc694aec9f0d
It was aimed at EXTSR in particular, it appear that the first SR to be plugged is the one choosing the mode of sr-mount since util.makedirs also create the parent directory with the given mode.
I have created a card for the issue on our side.
]]></description><link>https://xcp-ng.org/forum/topic/12462/run-sr-mount-parent-directory-created-0700-on-some-hosts-0755-on-others</link><guid isPermaLink="true">https://xcp-ng.org/forum/topic/12462/run-sr-mount-parent-directory-created-0700-on-some-hosts-0755-on-others</guid><dc:creator><![CDATA[dthenot]]></dc:creator><pubDate>Wed, 09 Sep 2026 08:25:04 GMT</pubDate></item><item><title><![CDATA[Nested virtualization  - Prevent migration]]></title><link>https://xcp-ng.org/forum/topic/12461/nested-virtualization-prevent-migration</link><guid isPermaLink="true">https://xcp-ng.org/forum/topic/12461/nested-virtualization-prevent-migration</guid><pubDate>Tue, 08 Sep 2026 20:31:55 GMT</pubDate></item><item><title><![CDATA[VM Display Resolution]]></title><description><![CDATA[It was too tempting not to test, so I went and tested the other half.
On an 8.3 host I set the preferred resolution to 800x600 in the OVMF menu on a UEFI Debian VM, turned that VM into a template, and cloned it.
The clone came up at 800x600.
A control clone of the same original, with nothing set, came up at 1024x768.
So your workaround holds, the resolution really does ride along into VMs built from the template.
For anyone who wants to poke at it, the setting is a UEFI variable called PlatformConfig under GUID 7235c51c-0c80-4cab-87ac-3b084a6304b1. It only appears in NVRAM once you commit it in the menu, and it stores width and height as plain little-endian integers, which is why it travels with the VM record.
One thing I didn't expect: the OVMF help text says the mode list is filtered against video RAM size, but the VM I used had the default 4 MB and still offered everything up to 1280x1024.
So you may not need to raise videoram for the common ones.
 Fair warning though, I measured the console at the firmware stage rather than after the distro's own driver takes over, so a guest that sets its own mode later could still override it.
At least, that's my understanding. 
]]></description><link>https://xcp-ng.org/forum/topic/12435/vm-display-resolution</link><guid isPermaLink="true">https://xcp-ng.org/forum/topic/12435/vm-display-resolution</guid><dc:creator><![CDATA[poddingue]]></dc:creator><pubDate>Tue, 25 Aug 2026 20:54:38 GMT</pubDate></item><item><title><![CDATA[Sudden boot issues, emergency shell, root-lfgrma does not exist]]></title><description><![CDATA[After a good sleep, I resolved half of my issue. I got my LSI Cards messed up, I accidentally hidan internal LSI3108 (Address 01:00.0) instead of the PCI Card LSI3008 (Address 05:00.0)...
My Boot Drives run off of the internal card.
From the fallback kernel, I was able to Modify /etc/grub-efi.cfg to remove the internal card form the hidden list.
I now have a separate issue, but will make another post.
]]></description><link>https://xcp-ng.org/forum/topic/12418/sudden-boot-issues-emergency-shell-root-lfgrma-does-not-exist</link><guid isPermaLink="true">https://xcp-ng.org/forum/topic/12418/sudden-boot-issues-emergency-shell-root-lfgrma-does-not-exist</guid><dc:creator><![CDATA[seanmcg182]]></dc:creator><pubDate>Sun, 16 Aug 2026 06:18:55 GMT</pubDate></item><item><title><![CDATA[Can't Reboot VMs (or Force Reboot) or Start VMs - Getting Blocked by SR.Scan - But Running VMs are fine?]]></title><description><![CDATA[Hard reboot sorted itself out 
]]></description><link>https://xcp-ng.org/forum/topic/12410/can-t-reboot-vms-or-force-reboot-or-start-vms-getting-blocked-by-sr.scan-but-running-vms-are-fine</link><guid isPermaLink="true">https://xcp-ng.org/forum/topic/12410/can-t-reboot-vms-or-force-reboot-or-start-vms-getting-blocked-by-sr.scan-but-running-vms-are-fine</guid><dc:creator><![CDATA[MichaelCropper]]></dc:creator><pubDate>Fri, 07 Aug 2026 16:37:21 GMT</pubDate></item><item><title><![CDATA[Smart Reboot blocked in XO, and no Rolling Pool Update]]></title><description><![CDATA[
@poddingue said:
What I can't tell you is what set that particular combination on your VM in the first place. Does it ring a bell?

I have no Idea. I had it on "Protect from accidental shutdown" but turned that off again, later. Doing this again (on, off) helped, as you said.
Thank you so much!
]]></description><link>https://xcp-ng.org/forum/topic/12409/smart-reboot-blocked-in-xo-and-no-rolling-pool-update</link><guid isPermaLink="true">https://xcp-ng.org/forum/topic/12409/smart-reboot-blocked-in-xo-and-no-rolling-pool-update</guid><dc:creator><![CDATA[djingo]]></dc:creator><pubDate>Fri, 07 Aug 2026 11:00:46 GMT</pubDate></item><item><title><![CDATA[Get a price quote on a plan]]></title><description><![CDATA[Hi,
I found your original request. I will make sure someone from the Sales team responds ASAP.
Regards,
Dan
]]></description><link>https://xcp-ng.org/forum/topic/12405/get-a-price-quote-on-a-plan</link><guid isPermaLink="true">https://xcp-ng.org/forum/topic/12405/get-a-price-quote-on-a-plan</guid><dc:creator><![CDATA[Danp]]></dc:creator><pubDate>Wed, 05 Aug 2026 10:52:36 GMT</pubDate></item><item><title><![CDATA[Autostart behaviour after upgrade 8.2 -> 8.3]]></title><description><![CDATA[I put both of your questions on a spare host, because I couldn't answer either from memory. 
On colons: xe creates a key literally called auto_poweron:true with an empty value, so the entries you saw were three separate keys and none was the real auto_poweron, and typing false afterwards just made another one.
It exits 0 and prints nothing every time, which I'd call a rough edge rather than a feature, though other-config is free-form by design so I don't know that the CLI is meant to validate keys at all.
On the sleep: with rc.local executable and no sleep, it fired at 16 seconds of uptime and xe appliance-start came back with Error: Connection refused (calling connect ), exit 1, in under a tenth of a second. The VM stayed halted and nothing was reported anywhere, since rc.local has no terminal to print to. rc-local.service only orders after basic.target and network.target, nothing toolstack-related, while xapi-wait-init-complete.service took 30 seconds on that host, which is presumably why 60 was barely enough for you.
There's an xapi-init-complete.target that looks like the right thing to order a unit against instead of guessing at a delay, though I haven't tried it so treat that as a lead rather than advice.
The executable-bit half is in the docs now, it went onto the troubleshooting page after you reported it: https://docs.xcp-ng.org/troubleshooting/common-problems
]]></description><link>https://xcp-ng.org/forum/topic/12389/autostart-behaviour-after-upgrade-8.2-8.3</link><guid isPermaLink="true">https://xcp-ng.org/forum/topic/12389/autostart-behaviour-after-upgrade-8.2-8.3</guid><dc:creator><![CDATA[poddingue]]></dc:creator><pubDate>Thu, 30 Jul 2026 11:12:37 GMT</pubDate></item><item><title><![CDATA[VM autostart stopped working]]></title><description><![CDATA[@poddingue Thank you for the analysis. I'd give you a rep if I could 
]]></description><link>https://xcp-ng.org/forum/topic/12388/vm-autostart-stopped-working</link><guid isPermaLink="true">https://xcp-ng.org/forum/topic/12388/vm-autostart-stopped-working</guid><dc:creator><![CDATA[Octopuss]]></dc:creator><pubDate>Wed, 29 Jul 2026 21:05:37 GMT</pubDate></item><item><title><![CDATA[Unable to live migrate VM between 2 local storages SR]]></title><description><![CDATA[I converted the topic to a question, then marked it solved. 
Thanks!
]]></description><link>https://xcp-ng.org/forum/topic/12352/unable-to-live-migrate-vm-between-2-local-storages-sr</link><guid isPermaLink="true">https://xcp-ng.org/forum/topic/12352/unable-to-live-migrate-vm-between-2-local-storages-sr</guid><dc:creator><![CDATA[poddingue]]></dc:creator><pubDate>Fri, 10 Jul 2026 09:01:38 GMT</pubDate></item><item><title><![CDATA[Can't restart stopped VMs; unclear error message]]></title><description><![CDATA[@the_jest
Not showen in this picutre but this is where the message would be displayed.  Next to the name of the host...
[image: 1782931263879-screenshot-2026-07-01-144023.png]
]]></description><link>https://xcp-ng.org/forum/topic/12331/can-t-restart-stopped-vms-unclear-error-message</link><guid isPermaLink="true">https://xcp-ng.org/forum/topic/12331/can-t-restart-stopped-vms-unclear-error-message</guid><dc:creator><![CDATA[acebmxer]]></dc:creator><pubDate>Wed, 01 Jul 2026 03:54:33 GMT</pubDate></item><item><title><![CDATA[HOST_NOT_ENOUGH_FREE_MEMORY during host.restart / host-evacuate despite destination having ample free RAM]]></title><description><![CDATA[PRs upstream are in review
]]></description><link>https://xcp-ng.org/forum/topic/12321/host_not_enough_free_memory-during-host.restart-host-evacuate-despite-destination-having-ample-free-ram</link><guid isPermaLink="true">https://xcp-ng.org/forum/topic/12321/host_not_enough_free_memory-during-host.restart-host-evacuate-despite-destination-having-ample-free-ram</guid><dc:creator><![CDATA[gthvn1]]></dc:creator><pubDate>Sun, 28 Jun 2026 01:52:19 GMT</pubDate></item><item><title><![CDATA[Start: no host available?]]></title><description><![CDATA[For your storage question, it's fully explained in the doc: https://docs.xcp-ng.org/storage/#-how-to-modify-an-existing-sr-connection
And yes, it's planned to get the complete error visible in XO, sadly, it's not "obvious" since the error message isn't returned by XAPI when you try to start but by another method we need to call after it fails ("assert can be started here" from the top of my head).
Let me ping @julienXOvates
]]></description><link>https://xcp-ng.org/forum/topic/12320/start-no-host-available</link><guid isPermaLink="true">https://xcp-ng.org/forum/topic/12320/start-no-host-available</guid><dc:creator><![CDATA[olivierlambert]]></dc:creator><pubDate>Fri, 26 Jun 2026 19:02:19 GMT</pubDate></item><item><title><![CDATA[14 VMs Running: After Pool patch update - message states I need to restart to take effect?]]></title><description><![CDATA[
@Danp said:
Smart Reboot option found on the host's Advanced tab does what you are asking

Very nice!   
]]></description><link>https://xcp-ng.org/forum/topic/12310/14-vms-running-after-pool-patch-update-message-states-i-need-to-restart-to-take-effect</link><guid isPermaLink="true">https://xcp-ng.org/forum/topic/12310/14-vms-running-after-pool-patch-update-message-states-i-need-to-restart-to-take-effect</guid><dc:creator><![CDATA[nasheayahu]]></dc:creator><pubDate>Wed, 24 Jun 2026 04:59:36 GMT</pubDate></item><item><title><![CDATA[xcp-ng update to latest june patch - error - requires: perl-interpreter]]></title><description><![CDATA[@AlexanderK you could try to install perl-interpreter manually maybe?
I happened to have a test host at hand that hasn't been updated since december, and the yum update went fine, perl interpreter was not installed before and yum update did install it on its own as a depency for openssl 3.
Maybe others will have ideas as to why this would happen in your case.
]]></description><link>https://xcp-ng.org/forum/topic/12303/xcp-ng-update-to-latest-june-patch-error-requires-perl-interpreter</link><guid isPermaLink="true">https://xcp-ng.org/forum/topic/12303/xcp-ng-update-to-latest-june-patch-error-requires-perl-interpreter</guid><dc:creator><![CDATA[bleader]]></dc:creator><pubDate>Sat, 20 Jun 2026 16:25:23 GMT</pubDate></item><item><title><![CDATA[cifs-utils LPE (CVE-2026-46243) / 8.3 dom0 vulnerability inquiry]]></title><description><![CDATA[Closing the loop on this one — VSA-2026-021 went up yesterday (June 10) covering CIFSwitch / CVE-2026-46243:
https://docs.vates.tech/security/advisories/2026/vates-sa-2026-021
A few things worth flagging for anyone following along:

Severity landed at Moderate 🟠 — same ballpark as CopyFail/DirtyFrag, as Lucien anticipated. XCP-ng 8.3 and XOA both confirmed affected.
XCP-ng 8.3 fix isn't in the main repo yet. The advisory notes there's a publicly available package with the fix, but it's not in the standard channel — Vates is asking people to reach out for the install procedure so you don't break future Rolling Pool Updates. So don't go hand-rolling the kernel commit yourself if you want to stay on the RPU path.
XOA is already handled — fixed in Debian kernel 6.1.174-1, pushed via the unattended update mechanism. Just note the XOA VM needs a restart for it to take effect, and anything older than Debian 11/12 won't get the update and needs an OS upgrade first.
Mitigation is unchanged from what we discussed: blacklist the cifs module if you're not using SMB-based SRs (which breaks SMB SRs, so only if you don't rely on them).


Good turnaround given the disclosure-to-advisory window. Thanks again @LucienLassalle and the security team.
]]></description><link>https://xcp-ng.org/forum/topic/12254/cifs-utils-lpe-cve-2026-46243-8.3-dom0-vulnerability-inquiry</link><guid isPermaLink="true">https://xcp-ng.org/forum/topic/12254/cifs-utils-lpe-cve-2026-46243-8.3-dom0-vulnerability-inquiry</guid><dc:creator><![CDATA[Rod G]]></dc:creator><pubDate>Tue, 02 Jun 2026 13:58:29 GMT</pubDate></item><item><title><![CDATA[Adding new host to pool fails - Stunnel SSL certiticate verification failure]]></title><description><![CDATA[@Bryanvh No problem 
The issue you encountered wasn't very clear. Therefore, I've proposed a change to the XAPI to make the error more explicit (this will likely be implemented in future XAPI releases).
So instead of SSL Certification failure the message will be: POOL_JOINING_MASTER_CERTIFICATE_NOT_IN_POOL_BUNDLE.
Thank you very much for your patience and for bringing this issue to our attention.
References:
https://github.com/xapi-project/xen-api/pull/7112
]]></description><link>https://xcp-ng.org/forum/topic/12244/adding-new-host-to-pool-fails-stunnel-ssl-certiticate-verification-failure</link><guid isPermaLink="true">https://xcp-ng.org/forum/topic/12244/adding-new-host-to-pool-fails-stunnel-ssl-certiticate-verification-failure</guid><dc:creator><![CDATA[LucienLassalle]]></dc:creator><pubDate>Tue, 26 May 2026 22:40:51 GMT</pubDate></item><item><title><![CDATA[[Solved] SR_SOURCE_SPACE_INSUFFICIENT - Problems enabling HA]]></title><description><![CDATA[@olivierlambert
Thanks again for your input and recomendations! I'll verify that this is solved by having the LUN expanded to 8GB instead. Afterwards I'll mark your answer as the solution!
]]></description><link>https://xcp-ng.org/forum/topic/12240/solved-sr_source_space_insufficient-problems-enabling-ha</link><guid isPermaLink="true">https://xcp-ng.org/forum/topic/12240/solved-sr_source_space_insufficient-problems-enabling-ha</guid><dc:creator><![CDATA[jr-m4]]></dc:creator><pubDate>Tue, 26 May 2026 06:28:16 GMT</pubDate></item><item><title><![CDATA[xe-gues-utilities woes on openSUSE Leap 16]]></title><description><![CDATA[@MajorP93 that’s fine - I never use ballooning anyway so I guess I am covered good 
]]></description><link>https://xcp-ng.org/forum/topic/12232/xe-gues-utilities-woes-on-opensuse-leap-16</link><guid isPermaLink="true">https://xcp-ng.org/forum/topic/12232/xe-gues-utilities-woes-on-opensuse-leap-16</guid><dc:creator><![CDATA[damjank]]></dc:creator><pubDate>Wed, 20 May 2026 17:09:18 GMT</pubDate></item><item><title><![CDATA[XOA vulnerabilty to "copy fail" and "dirty frag" bug]]></title><description><![CDATA[Quick update now that Vates has published their official advisory.
First, kudos to the Vates security team for the thorough and timely response. VSA-2026-014 is well-documented and covers the full picture, including a third CVE I had not covered in my earlier posts.
VSA-2026-014 confirms what I outlined above: XCP-ng is affected by CVE-2026-43284 (XFRM-ESP) and is NOT affected by CVE-2026-43500 (no RxRPC support). The CVE I had missed: CVE-2026-46300 ("Fragnesia") also affects XCP-ng via the XFRM ESP-in-TCP subsystem. The same esp4/esp6 blacklist mitigation applies, with the same caveat @semarie raised: it will break encrypted private networks on XCP-ng.
Now that the VSA and official mitigation guidance are public, I'm releasing the diagnostic script I built. It's Python 3.6, no external dependencies, safe to run on production dom0. It tests whether an unprivileged process can engage the esp4 engine via the XFRM interface inside a user namespace — without touching any exploit code. Since both CVE-2026-43284 and CVE-2026-46300 (Fragnesia) require esp4 or esp6 to be reachable from an unprivileged namespace, and share the same mitigation, a positive result confirms exposure to both. Blacklist esp4/esp6, then run the script again — ACCESS DENIED means both CVEs are mitigated.
One important note before running it: please read the code before executing it on any of your systems. This is good practice with any script from the internet, regardless of the source. The code is intentionally short and straightforward so you can review it quickly and satisfy yourself that it does exactly what it says.
 VSA-2026-014: https://docs.vates.tech/security/advisories/2026/vates-sa-2026-014/
 Diagnostic tool: https://github.com/grabesec/XCP_ng_CVE-2026-43284_tester
A kernel patch from Vates is in progress. Apply as soon as it lands.
]]></description><link>https://xcp-ng.org/forum/topic/12204/xoa-vulnerabilty-to-copy-fail-and-dirty-frag-bug</link><guid isPermaLink="true">https://xcp-ng.org/forum/topic/12204/xoa-vulnerabilty-to-copy-fail-and-dirty-frag-bug</guid><dc:creator><![CDATA[Rod G]]></dc:creator><pubDate>Sat, 09 May 2026 10:49:46 GMT</pubDate></item><item><title><![CDATA[Revert to snapshot, resets creation date. Intended behaviour?]]></title><description><![CDATA[@poddingue
Thanks for your input.
Yes I'm aware that basically everything on the VM is incorporated into the snapshot. Including settings and metadata. This is acctually why I was surprised that the creation date wasn't preserved as part of that metadata.  And as you say, if one uses that metric to track VM history. Then it can, and will, throw you off.
I'll gladly submit this as a feature request. But my gut feeling is that it is more akin to a bug than missing feature per se.
Thanks!
]]></description><link>https://xcp-ng.org/forum/topic/12148/revert-to-snapshot-resets-creation-date.-intended-behaviour</link><guid isPermaLink="true">https://xcp-ng.org/forum/topic/12148/revert-to-snapshot-resets-creation-date.-intended-behaviour</guid><dc:creator><![CDATA[jr-m4]]></dc:creator><pubDate>Tue, 05 May 2026 14:22:04 GMT</pubDate></item><item><title><![CDATA[Question about pools]]></title><description><![CDATA[@vlamincktr  XO PROXY from source is pretty reliable at no cost
either use @acebmxer script or @ronivay
here is a quick tuto on an ubuntu VM
https://omnibox.huducloud.com/shared_article/QJ9y1bRSPj9VTbWp6NKaV7yn/installation-xoa-a-partir-des-sources-github-ronivay
first part is XO CE, second part is XO PROXY CE
beware as you delegate some jobs to XO PROXY, to ever upgrade XO PROXY when you upgrade XOA, so that they have the same backup mechanisms/code
]]></description><link>https://xcp-ng.org/forum/topic/12147/question-about-pools</link><guid isPermaLink="true">https://xcp-ng.org/forum/topic/12147/question-about-pools</guid><dc:creator><![CDATA[Pilow]]></dc:creator><pubDate>Tue, 05 May 2026 14:17:54 GMT</pubDate></item><item><title><![CDATA[Alcatel OXE on XCP-ng – anyone done this before?]]></title><description><![CDATA[Ah very good, so it was even easier than this. You had the Xen blk driver but instead of using an UUID, the appliance was having a hardcoded sda.
Keep us posted 
]]></description><link>https://xcp-ng.org/forum/topic/12098/alcatel-oxe-on-xcp-ng-anyone-done-this-before</link><guid isPermaLink="true">https://xcp-ng.org/forum/topic/12098/alcatel-oxe-on-xcp-ng-anyone-done-this-before</guid><dc:creator><![CDATA[olivierlambert]]></dc:creator><pubDate>Fri, 24 Apr 2026 07:20:51 GMT</pubDate></item><item><title><![CDATA[Storage domain server & Rolling pool upgrade]]></title><description><![CDATA[
@gregoire said:
@olivierlambert I added this feature request in the backlog regarding RPU improvements.

Hello,
Thanks all !
Totally agree with @poddingue , be able to exclude VM which has:

PCI attached devices
Local storage ( maybe ? )

Could be a great option ! 
]]></description><link>https://xcp-ng.org/forum/topic/12081/storage-domain-server-rolling-pool-upgrade</link><guid isPermaLink="true">https://xcp-ng.org/forum/topic/12081/storage-domain-server-rolling-pool-upgrade</guid><dc:creator><![CDATA[henri9813]]></dc:creator><pubDate>Wed, 15 Apr 2026 08:38:09 GMT</pubDate></item><item><title><![CDATA[CPU Usage of empty server]]></title><description><![CDATA[i think im seeing the same with fake cpu spikes. I started a second pool yesterday to patch and left it on over night. typically i just shut it down once done so the servers dont get too far behind patching.
Under the pool stats im seeing spikes but under hosts nothing.
It doesnt really bother me, but figure i add to the thread that im also seeing it.
[image: 1784817154694-c75fecec-d618-4f05-a931-edea6bc6ecce-image-resized.jpeg]
[image: 1784817189696-1b9ea5aa-d349-4ff8-af89-30a970d36fbb-image-resized.jpeg]
[image: 1784817219194-0f579999-cd96-4216-a0d4-d637ea5febf1-image-resized.jpeg]
]]></description><link>https://xcp-ng.org/forum/topic/12055/cpu-usage-of-empty-server</link><guid isPermaLink="true">https://xcp-ng.org/forum/topic/12055/cpu-usage-of-empty-server</guid><dc:creator><![CDATA[marcoi]]></dc:creator><pubDate>Mon, 06 Apr 2026 07:54:18 GMT</pubDate></item></channel></rss>