@Greg_E said in Building XCP-ng from source code: @olivierlambert Ok, thanks. Yes I'm eagerly awaiting XCP-ng 9 for testing. Hi, check this thread: https://xcp-ng.org/forum/topic/11698/xcp-ng-9.0-demonstrator-early-preview More coming...

@MathieuRA I disabled Traefik and reverted to my old XO config (port 443, ssl encryption, http to https redirection), rebuild the docker container using your branch and tested: it is working fine on my end now Thank you very much! I did not expect this to get fixed so fast!

@MajorP93 Thanks for your feedback. I'll look into it over the christmas hollidays

@benapetr Thanks, I will have to play with this when I have time.

@firereverie Sorry, these last few weeks was very-very busy. So I REALLY hope will do something on this before the december end and come back to you.

@Pilow I will take a look in deep later, but the key/delta and disk usage is set during backup, even if they are merged during LTR retention

In case anyone wonders how this played out. At the end of the day, I shutdown the host with the running workloads on it, kept it at BIOS boot so the 8.3 installer would upgrade it cleanly, and then booted it back up. For reasons related to my particular setup, the down time was more than 60 minutes. But that's not related to XCP-ng. The XCP-ng installer was maybe 10 of that. 20 of that was 3 reboots on a server that takes ages to boot. One thing that is a bit difficult is that the 8.3 installer doesn't notice ZFS volumes or help with ZFS. So after the upgrade, I have to follow a modified set of these instructions (modified because the package names have changed over time) to install ZFS and its components into the system. So the sequence is: Shutdown Install via ISO Reboot to single user mode Run yum update to pull in all the updates Run the ZFS commands to install ZFS on the host Reboot again Run normally Of course, I ended up rebooting more than just those 2 times, because I forgot that I would need to install ZFS (even though I did it on 2 different hosts already ) So now the pool is fully upgraded, everybody is happy. I'm now working on creating shared storage across the nodes. It's amateur hour over here. I appreciate all the help.

Another thing that I noticed: despite enabling remote syslog (to graylog) for all XCP-ng hosts in the pool /var/log gets filled up to 100%. Adding remote syslog seem to not change usage of /var/log at all. Official XCP-ng documentation states otherwise here: https://docs.xcp-ng.org/installation/install-xcp-ng/#installation-on-usb-drives The linked part of the documentation indicates that configuring remote syslog can be a possible solution for /var/log space constraints which seems to be not the case. I feel like logging could use some investigation by Vates in general.

Hi, I can't tell it's the cause, but you should first use an officially supported client to manage it.

@Greg_E said in XCP-ng Windows PV tools announcements: @john.c I'll have to update group policy and check that out, would be a time saver. Everything I use is an Enterprise level of some kind, using EDU in production right now, and Pro/Enterprise evaluation in the lab. I was looking at running a post imaging script to prevent some of the bloat, but a GPO might be easier. You can use Windows ADK to customise the installation media and build a custom ISO. That file can then be placed on your ISO SR. The GPO is especially effective when combined with a custom ISO built using Windows ADK. I have tried this myself and it’s very effective doing it this way, the Windows ADK tool is very powerful but will require time to learn. Will save time with all of the extra installations, if you use a custom ISO.

hardware_report_2025-12-12_17-20-47.txt lspci.txt mlx.txt pci.txt Diagnostic logs

@denis.grilli really big news, I need to have XO STOR working Thanks for your problems and support correting them

It won't disappear tomorrow, but I'd like to phase it out sooner than later (before 2027? who knows)

It's not meant to be used like that. If you are behind a NAT, the right approach is to have your XOA behind the NAT and inside the same network than the hosts. That's because hosts will always use and return their internal IPs to connect to some resources (stats, consoles etc.). XOA deals with that easily as being the "main control point" for all hosts behind your NAT (or a XO proxy if you prefer).

@ovicz Yes, it's loaded lsmod | grep i915 i915 5373952 0 i2c_algo_bit 20480 2 xe,i915 drm_buddy 32768 2 xe,i915 video 81920 2 xe,i915 ttm 135168 3 drm_ttm_helper,xe,i915 drm_display_helper 331776 2 xe,i915 cec 106496 3 drm_display_helper,xe,i915 dmesg starts the same as your output, the only difference is that I have GuC disabled. dmesg | grep i915 [ 1.609000] i915 0000:00:08.0: [drm] Found alderlake_s (device ID 4690) integrated display version 12.00 stepping C0 [ 1.609986] i915 0000:00:08.0: [drm] VT-d active for gfx access [ 1.610073] i915 0000:00:08.0: [drm] Using Transparent Hugepages [ 1.611342] i915 0000:00:08.0: Invalid PCI ROM header signature: expecting 0xaa55, got 0x4556 [ 1.611345] i915 0000:00:08.0: [drm] Failed to find VBIOS tables (VBT) [ 1.612136] i915 0000:00:08.0: vgaarb: VGA decodes changed: olddecodes=io+mem,decodes=none:owns=io+mem [ 1.614455] i915 0000:00:08.0: [drm] Finished loading DMC firmware i915/adls_dmc_ver2_01.bin (v2.1) [ 3.583673] i915 0000:00:08.0: [drm] [ENCODER:261:DDI A/PHY A] failed to retrieve link info, disabling eDP [ 3.605422] i915 0000:00:08.0: [drm] GT0: GuC firmware i915/tgl_guc_70.bin version 70.49.4 [ 3.605426] i915 0000:00:08.0: [drm] GT0: HuC firmware i915/tgl_huc.bin version 7.9.3 [ 3.615402] i915 0000:00:08.0: [drm] GT0: HuC: authenticated for all workloads [ 3.615410] i915 0000:00:08.0: [drm] GT0: GUC: submission disabled [ 3.615414] i915 0000:00:08.0: [drm] GT0: GUC: SLPC disabled [ 3.616508] i915 0000:00:08.0: [drm] Protected Xe Path (PXP) protected content support initialized [ 3.617330] i915 0000:00:08.0: [drm] Registered 4 planes with drm panic [ 3.617354] [drm] Initialized i915 1.6.0 for 0000:00:08.0 on minor 1 [ 3.627390] i915 0000:00:08.0: [drm] Cannot find any crtc or sizes [ 3.637349] i915 0000:00:08.0: [drm] Cannot find any crtc or sizes [ 3.657358] i915 0000:00:08.0: [drm] Cannot find any crtc or sizes Having edited /etc/modprobe.d/i915.conf by adding options i915 enable_guc=3 enable_huc=1 fixed the GuC part as well, however I still have the same issue. Cannot find any crtc or sizes is the only part which is not in your output. /etc/default/grub is clean, I don't have NOMODESET: cat /etc/default/grub GRUB_TIMEOUT=5 GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)" GRUB_DEFAULT=saved GRUB_DISABLE_SUBMENU=true GRUB_TERMINAL_OUTPUT="console" GRUB_CMDLINE_LINUX="rd.lvm.lv=fedora/root rhgb quiet" GRUB_DISABLE_RECOVERY="true"

The roadmap depends a lot on the feedback we have on it More demand/popular, faster we'll implement stuff

Ok I've figured out root cause. My config override has only one option: ignoreVmSnapshotResources = true And I had to change it with adding [selfService] on a line below Also I found out that override config for XO5 interface needs to have absolute paths to xo-web and @XenOrchestra in it. With relative paths it didn't work.