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.

Feel free to create a trial on an XOA, test stable and latest and tell us. It might be also related to your environment, but if it works at some commit and not later, it's weird. @florent & @bastien-nollet maybe?

Great! Keep us posted

@MathieuRA The context for my question is I created an app to control my VMs and though my app said a VM started it really didn't. When I went into the logs I noticed an error, so my thought is to be able to check the logs would be helpful to find out if there is an error or not. Let me update my app because I'm thinking I can get around not having access to the logs. Thank you for the prompt response! Have a blessed day!

In other words, you can safely remove them.

@dinhngtu Seems like an issue for this already exists: https://github.com/xcp-ng/xenadmin/issues/260 Added what I wrote above as a comment. Gnggi created this issue in xcp-ng/xenadmin open Showing wrong Virtualization state for VMs with Management agent 9.1.100 #260

@vhaelan Is the intel graphics module loaded ? lsmod | grep i915 i915 5373952 24 drm_buddy 32768 2 xe,i915 ttm 135168 3 drm_ttm_helper,xe,i915 i2c_algo_bit 20480 2 xe,i915 drm_display_helper 331776 2 xe,i915 cec 106496 3 drm_display_helper,xe,i915 video 81920 2 xe,i91 sudo dmesg | grep i915 [ 5.855595] i915 0000:00:08.0: [drm] Found alderlake_p/alderlake_n (device ID 46d1) integrated display version 13.00 stepping D0 [ 5.858477] i915 0000:00:08.0: [drm] VT-d active for gfx access [ 5.858739] i915 0000:00:08.0: [drm] Using Transparent Hugepages [ 5.859307] i915 0000:00:08.0: Invalid PCI ROM header signature: expecting 0xaa55, got 0x4556 [ 5.859312] i915 0000:00:08.0: [drm] Failed to find VBIOS tables (VBT) [ 5.860012] i915 0000:00:08.0: vgaarb: VGA decodes changed: olddecodes=io+mem,decodes=none:owns=io+mem [ 5.878556] i915 0000:00:08.0: [drm] Finished loading DMC firmware i915/adlp_dmc.bin (v2.20) [ 7.806109] i915 0000:00:08.0: [drm] [ENCODER:204:DDI A/PHY A] failed to retrieve link info, disabling eDP [ 7.843768] i915 0000:00:08.0: [drm] GT0: GuC firmware i915/tgl_guc_70.bin version 70.49.4 [ 7.843776] i915 0000:00:08.0: [drm] GT0: HuC firmware i915/tgl_huc.bin version 7.9.3 [ 7.849282] i915 0000:00:08.0: [drm] GT0: HuC: authenticated for all workloads [ 7.850868] i915 0000:00:08.0: [drm] GT0: GUC: submission enabled [ 7.850874] i915 0000:00:08.0: [drm] GT0: GUC: SLPC enabled [ 7.851225] i915 0000:00:08.0: [drm] GT0: GUC: RC enabled [ 7.852797] i915 0000:00:08.0: [drm] Protected Xe Path (PXP) protected content support initialized [ 7.854314] i915 0000:00:08.0: [drm] Registered 3 planes with drm panic [ 7.854318] [drm] Initialized i915 1.6.0 for 0000:00:08.0 on minor 1 Also see in /etc/default/grub if there is NOMODESET in GRUB_CMDLINE_LINUX line. That's from my Fedora 43 vm with passthrough enabled.

okay weird. Let's see if there's other reports then

Thanks Olivier! That is what we assumed, but with how the 3 hosts per pool was in there under the essentials licenses it was up for debate

But giving your feedback on how you solved it might help many people in the future Thanks!

@Forza you will have to switch to LATEST to profit from end month release STABLE is one version behind LATEST both are production ready.

@ph7 Thank you!

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

Hmm it sounds like a hardware issue from here Let me ask https://xcp-ng.org/forum/groups/team-os-platform-release

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.

@Bastien-Nollet Great, thanks!

Figured it out after some digging, appears it's related to Netbox having ipv4 translated into ipv6 for that field, so to use IPv4 you have to have :ffff:x.x.x.x/128 as your IP address (the x's being your octet). Once you do this it works without issue.

I'm seeing something similar, not sure if its the same issue, but mine stops at 95% and just hangs there: [12:18 sto-xcp1 ~]# xe task-list uuid ( RO) : c1056d36-b195-056a-4121-e82d7fc851fb name-label ( RO): [XO] Importing content into VDI [ESXI]DEBIAN 12 fiona.iextreme.org-flat.vmdk on SR Local storage name-description ( RO): status ( RO): pending progress ( RO): 0.950 The nbdkit debug-log can be found here: https://mirror2.iextreme.org/temp/stderr Edit: some additional info Xen Orchestra, commit 1640a Master, commit 1640a