@dlucas said in XCP-NG 8.3 Crash on Shutdown - HP DL360 g9: Have checked the IML log and the only thing that is being logged is this: "13","Critical","PCI Bus","12/04/2025 00:03","12/04/2025 00:03","1","PCI Bus Error (Slot 0, Bus 0, Device 2, Function 2)", "12","Critical","PCI Bus","12/03/2025 23:01","12/03/2025 23:01","1","PCI Bus Error (Slot 0, Bus 0, Device 2, Function 2)", "11","Critical","PCI Bus","12/03/2025 22:53","12/03/2025 22:53","1","PCI Bus Error (Slot 0, Bus 0, Device 2, Function 2)", "10","Critical","PCI Bus","12/01/2025 23:44","12/01/2025 23:44","1","PCI Bus Error (Slot 0, Bus 0, Device 2, Function 2)", "9","Critical","PCI Bus","12/01/2025 01:31","12/01/2025 01:31","1","PCI Bus Error (Slot 0, Bus 0, Device 2, Function 2)", I thought that a shutdown command from the command prompt solved the issue but it seems to always reboot when ever you tell it to shutdown. What is device 00:02.2 (through lspci) ?

@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

I'm curious about this, too, though for a different reason. I installed a real certificate onto my XCP-ng host, and the login page works fine. But after I log in, I get an error about an unreachable host since it's trying to access resources by IP address (and, since it's a real certificate signed by a trusted CA, doesn't have the IP address as a SAN entry). So, I click the link to open the IP address in a new tab, allow the cert mismatch, and then I'm good to reload the original tab. Basically, navigating to XO Lite via an FQDN doesn't work without some fiddling unless you run your own CA and can enter the IP addresses on the certs you generate (and trust its certs on your endpoints).

Very similar situation on our end. Lots of back and forth with support. Basically, given up now. The latest patch seemed to have helped a bit but overall not a production ready product yet.

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.

We do warn about the certificate situation in the 8.3 release notes, indeed, but it's easy to get caught by that. There's a way to temporarily disable LTS verification on the new hosts in order to join it to the existing pool. See https://docs.xcp-ng.org/releases/release-8-3/#certificate-verification-xs which in turns points to https://docs.xenserver.com/en-us/xenserver/8/hosts-pools/certificate-verification where you'll find that command. Regarding your initial situation, I'm not 100% sure, but I think Warm Migration, might be a way to migrate your VMs off your slave hosts while minimizing downtime. I don't know how it plays with CBT and heterogenous pool state exactly though.