OK, not really sure what's going on. I fired XCP back up to try what @teddyastie suggested. Looking at the specs for the TrueNAS VM before booting it, it now had zero passthrough devices attached, which wasn't the state of the last time I tried (from memory). So re-added all but 1 passthrough, a GPU. Booted TrueNAS and this time it came up. Bingo, I thought, the GPU is the issue, but based on my background, I had to try again with the GPU included to prove it was the culprit. Well, what do you know, after adding it back in, TrueNAS now starts perfectly. One theory destroyed. All I can think, is that somehow the passthrough definitions in the VM config were corrupted and finding them all gone and re-adding them fixed this. Who knows. But all appears to be good again (for now).

@TeddyAstie Hi thanks for your message, This is the output from the R620 xl info host : RHS-XCP-Host release : 4.19.0+1 version : #1 SMP Thu Jan 13 12:55:45 CET 2022 machine : x86_64 nr_cpus : 24 max_cpu_id : 47 nr_nodes : 2 cores_per_socket : 6 threads_per_core : 2 cpu_mhz : 2600.017 hw_caps : bfebfbff:77bee3ff:2c100800:00000001:00000001:00000281:00000000:00000100 virt_caps : pv hvm hvm_directio pv_directio hap shadow iommu_hap_pt_share total_memory : 262080 free_memory : 147511 sharing_freed_memory : 0 sharing_used_memory : 0 outstanding_claims : 0 free_cpus : 0 xen_major : 4 xen_minor : 13 xen_extra : .4-9.19.1 xen_version : 4.13.4-9.19.1 xen_caps : xen-3.0-x86_64 hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64 xen_scheduler : credit xen_pagesize : 4096 platform_params : virt_start=0xffff800000000000 xen_changeset : 6e2fc128eb1a, pq dd3d13f0a45e xen_commandline : dom0_mem=7584M,max:7584M watchdog ucode=scan dom0_max_vcpus=1-16 crashkernel=256M,below=4G console=vga vga=mode-0x0311 cc_compiler : gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-28) cc_compile_by : mockbuild cc_compile_domain : [unknown] cc_compile_date : Wed Feb 9 12:07:47 CET 2022 build_id : b709b0bb6a0cad9906689853f5bc629ba4b3e23f xend_config_format : 4 R620 is running 8.2.1 plan on upgrade though, This is the output from the R720 which is running 8.3 host : r720vm release : 4.19.0+1 version : #1 SMP Tue May 6 15:24:43 CEST 2025 machine : x86_64 nr_cpus : 24 max_cpu_id : 47 nr_nodes : 2 cores_per_socket : 6 threads_per_core : 2 cpu_mhz : 1999.999 hw_caps : bfebfbff:1fbee3ff:2c100800:00000001:00000001:00000000:00000000:00000100 virt_caps : pv hvm hvm_directio pv_directio hap gnttab-v1 gnttab-v2 total_memory : 131007 free_memory : 98858 sharing_freed_memory : 0 sharing_used_memory : 0 outstanding_claims : 0 free_cpus : 0 xen_major : 4 xen_minor : 17 xen_extra : .5-13 xen_version : 4.17.5-13 xen_caps : xen-3.0-x86_64 hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64 xen_scheduler : credit xen_pagesize : 4096 platform_params : virt_start=0xffff800000000000 xen_changeset : 430ce6cd9365, pq 3941a9ecb541 xen_commandline : dom0_mem=7584M,max:7584M watchdog ucode=scan dom0_max_vcpus=1-16 crashkernel=256M,below=4G console=vga vga=mode-0x0311 cc_compiler : gcc (GCC) 11.2.1 20210728 (Red Hat 11.2.1-1) cc_compile_by : mockbuild cc_compile_domain : [unknown] cc_compile_date : Tue May 13 11:56:07 CEST 2025 build_id : 276c39c6465df3ee400d28199a52e4760162470e xend_config_format : 4 output from xl dmesg R720, I cannot post xl dmesg however with passthrough to the VM the host is reporting the following relating to vd-d, (XEN) [ 5.749249] Brought up 24 CPUs (XEN) [ 5.763020] Testing NMI watchdog on all CPUs:ok (XEN) [ 5.876546] Scheduling granularity: cpu, 1 CPU per sched-resource (XEN) [ 5.890556] mcheck_poll: Machine check polling timer started. (XEN) [ 5.924606] NX (Execute Disable) protection active (XEN) [ 5.938382] d0 has maximum 3416 PIRQs (XEN) [ 5.952084] csched_alloc_domdata: setting dom 0 as the privileged domain (XEN) [ 5.965967] *** Building a PV Dom0 *** (XEN) [ 6.298965] Xen kernel: 64-bit, lsb (XEN) [ 6.312489] Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x302c000 (XEN) [ 6.327086] PHYSICAL MEMORY ARRANGEMENT: (XEN) [ 6.340730] Dom0 alloc.: 0000001ff0000000->0000001ff4000000 (1920491 pages to be allocated) (XEN) [ 6.355230] Init. ramdisk: 000000203edeb000->000000203ffff70b (XEN) [ 6.369315] VIRTUAL MEMORY ARRANGEMENT: (XEN) [ 6.383053] Loaded kernel: ffffffff81000000->ffffffff8302c000 (XEN) [ 6.396886] Phys-Mach map: 0000008000000000->0000008000ed0000 (XEN) [ 6.410703] Start info: ffffffff8302c000->ffffffff8302c4b8 (XEN) [ 6.424553] Page tables: ffffffff8302d000->ffffffff8304a000 (XEN) [ 6.438320] Boot stack: ffffffff8304a000->ffffffff8304b000 (XEN) [ 6.452059] TOTAL: ffffffff80000000->ffffffff83400000 (XEN) [ 6.465789] ENTRY ADDRESS: ffffffff8242b180 (XEN) [ 6.481017] Dom0 has maximum 16 VCPUs (XEN) [ 6.586427] Masked UR signaling on 0000:00:00.0 (XEN) [ 6.599996] Found masked UR signaling on 0000:00:01.0 (XEN) [ 6.613599] Found masked UR signaling on 0000:00:01.1 (XEN) [ 6.627188] Found masked UR signaling on 0000:00:02.0 (XEN) [ 6.640830] Found masked UR signaling on 0000:00:02.2 (XEN) [ 6.654539] Found masked UR signaling on 0000:00:03.0 (XEN) [ 6.668125] Found masked UR signaling on 0000:00:03.2 (XEN) [ 6.681745] Masked VT-d error signaling on 0000:00:05.0 (XEN) [ 6.713524] Found masked UR signaling on 0000:40:01.0 (XEN) [ 6.727164] Found masked UR signaling on 0000:40:02.0 (XEN) [ 6.740897] Found masked UR signaling on 0000:40:03.0 (XEN) [ 6.754561] Found masked UR signaling on 0000:40:03.2 (XEN) [ 6.768225] Masked VT-d error signaling on 0000:40:05.0 (XEN) [ 16.159374] Initial low memory virq threshold set at 0x4000 pages. (XEN) [ 16.173083] Scrubbing Free RAM in background (XEN) [ 16.186689] Std. Loglevel: Errors, warnings and info (XEN) [ 16.200411] Guest Loglevel: Nothing (Rate-limited: Errors and warnings) (XEN) [ 16.214412] *************************************************** (XEN) [ 16.228050] Booted on L1TF-vulnerable hardware with SMT/Hyperthreading (XEN) [ 16.241806] enabled. Please assess your configuration and choose an (XEN) [ 16.255669] explicit 'smt=<bool>' setting. See XSA-273. (XEN) [ 16.269483] *************************************************** (XEN) [ 16.283372] Booted on MLPDS/MFBDS-vulnerable hardware with SMT/Hyperthreading (XEN) [ 16.297418] enabled. Mitigations will not be fully effective. Please (XEN) [ 16.311534] choose an explicit smt=<bool> setting. See XSA-297. (XEN) [ 16.325707] *************************************************** (XEN) [ 16.339991] 3... 2... 1... (XEN) [ 19.353800] Xen is relinquishing VGA console. (XEN) [ 19.411460] *** Serial input to DOM0 (type 'CTRL-a' three times to switch input) (XEN) [ 19.412014] Freed 2048kB init memory (XEN) [ 28.498008] Found masked UR signaling on 0000:00:00.0 (XEN) [ 28.498616] Found masked UR signaling on 0000:00:01.0 (XEN) [ 28.499192] Found masked UR signaling on 0000:00:01.1 (XEN) [ 28.499878] Found masked UR signaling on 0000:00:02.0 (XEN) [ 28.500461] Found masked UR signaling on 0000:00:02.2 (XEN) [ 28.501128] Found masked UR signaling on 0000:00:03.0 (XEN) [ 28.501759] Found masked UR signaling on 0000:00:03.2 (XEN) [ 28.502227] Masked VT-d error signaling on 0000:00:05.0 (XEN) [ 28.556213] Found masked UR signaling on 0000:40:01.0 (XEN) [ 28.556880] Found masked UR signaling on 0000:40:02.0 (XEN) [ 28.557563] Found masked UR signaling on 0000:40:03.0 (XEN) [ 28.558191] Found masked UR signaling on 0000:40:03.2 (XEN) [ 28.558674] Masked VT-d error signaling on 0000:40:05.0 Regards

@Aleksander YMMV as XCP-NG is not a supported hypervisor. (XenServer is supported) https://docs.nvidia.com/vgpu/deployment/index.html

OK, I still had my old pool master registered as a server in XO (disabled), removing this and restarting XO now shows the VMs properly in the audit logs when snapshot, and it shows them being initiated by my XO IP, but the snapshots are still seen as detached ("Missing VM"). Maybe it will just resolve itself eventually if XAPI is holding onto stale references? I still have my old backups ("Detached backups") that I'm waiting to remove (job itself removed), maybe that's also impacting things - I will be removing the backed up VHDs once my NAS has copied them to an external drive (very slow!). I'm not opposed to blowing XO away and starting it over, I need to start a new backup job anyway - if there's a procedure/best practice to go by in order to re-create all the metadata I'd be interested.

@DustyArmstrong thats super-strange, i actually have the same setup at home, 2 hp z240 machines running xcp-ng in a small pool. xcp1 is always up and running, xcp2 is powered down when I dont need it, everything important is running on xcp1, maybe that's the reason I don't run into these issues.

@DustinB said in Recommended DELL Hardware ?: Doesn't using non-shared storage ultimately cause the VM to be started on the other host? No. Live migration can occur between hosts even if: the VDI are located on non-shared storage the hosts are in completely different pools For the cross pool migration to succeed, both pools need to support a common instruction set. Otherwise, use the Warm Migration feature that does reboot the VM so that it is running the correct instruction set on the destination host.

@blueh2o said in Health check scripts. Where is the example?: xen-orchestra/backups/docs/healthcheck example/wait30seconds.sh that would be here https://github.com/vatesfr/xen-orchestra/tree/master/%40xen-orchestra/backups/docs

@yeopil21 you can target vsphere it should work The issue here is that XO fail to link one of your datastore to the datacenter is it XO from source or a XOA ? you should have in your server logs something like can't find datacenter for datastore with the datacenters and the datastore name as detected by XO are you using an admin account on vsphere or is it a limited one ?

@florent Thanks again for your assistance, greatly appreciated.

@Pilow we are still working on it, but for now we didn't find a solution

@jqueiroz said in Second IP for Hosts Interface: I have a situation where I would like to add a second IPv4 address to the management interface of a host. I am installing a host that will be used in another location and I would like to add the address of that location to the management interface before shipping the machine there. Is it possible to do this, or should I continue using the current procedure (making the necessary configurations and change the address shortly before shutting down the machine and packing it for transport)? there is a nuance between secondary IP and secondary MANAGEMENT IP if you have multiple NICS, you could add & configure the destination site IP on it, but it is not flagged management yet. once the server gets on the new site, you could access web ui by this IP address (or SSH) and then either go to web console/xs server or SSH and do the necessary to change management to the good PIF/IP ?

I just released 0.0.4! Still an alpha, but it's becoming pretty usable - there was over 60 commits of code cleanup, polish and also limited testing of all visible features - pretty much everything that is now visible in the UI should be operational at this point, option pages, properties of hosts, pools, VDIs, configuration of NICs, even bonding and advanced stuff like pool password / secret rotation. All XAPI actions and commands were already ported over from C# variant, so my focus now is only on finishing it into a final usable product. We also have some features that original client doesn't have (such as XenCache explorer)! Next on my to-do is to add all features that are currently missing completely: HA, GPU, PCIe, VM import / export etc. Note: I will not be porting over any licensed or proprietary Citrix stuff. This tool may work with XenServer just fine, but I will not be porting over any of the proprietary features, because I will never use it and I have no way to test it either.

Ok, my syntax is oudated. resize_rootfs: true growpart: mode: auto devices: ['/dev/xvda3'] ignore_growroot_disabled: false runcmd: - pvresize /dev/xvda3 - lvextend -r -l +100%FREE /dev/ubuntu-vg/ubuntu-lv || true this one works. final_message. doesn't support any macro like %(uptime) %(UPTIME)

@Pilow said in Unable to copy template: something preventing you to patch thoses hosts ? yes.

@MajorP93 It's being packaged at the moment. between this and the testing that needs to be done it might take a couple of weeks to be released, but I can't promise anything yet

@olivierlambert New thread is here

It is difficult to know the source of the problem without more details from your logs. Can you run the following commands on your XCP-ng host and then attach the generated files here? grep -A 15 -B 15 -i error /var/log/xensource.log/xensource > xensource.txt grep -A 15 -B 15 -i exception /var/log/SMlog > smlog.txt dmesg -T|grep -Eiv 'guest|capacity|promiscuous' > dmesg.txt

@nathanael-h I have not yet tried the XO CSI driver, if I do I will leave feedback on the relevant thread. (I found the one started in 2025 November)