@AtaxyaNetwork @Pilow @bvitnik Ok, knowing that the p2 partition was likely an old backup was exactly the breadcrumb that I needed. I confirmed via chroot and xsconsole that p2 was xcp-ng v8.2.1, and that p1 was v8.3. Then I was able to check the initrd files there. Namely I needed to see the updated dates and the kernel version. Thankfully, I saw initrd files on the backup that were the correct kernel and hadn't been disturbed. I then just cloned the initrd files from the backup partition to the p1 partition and BOOM. We booted right up. Much appreciated for the assistance, everyone. I'll still need to figure out why my disks are disconnecting, but that will be another post for another day.

I will tell you a little secret, you taught me more than that one command for CLI lol One more important note for my Bitwarden Thanks again bud!

@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.

@Bastien-Nollet Great, thanks!

@acebmxer Great. These are some YAML basics. You should read more about it . Following AI instructions without understanding is not going to take you far.

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

@Pilow alright, cool! that sounds pretty much like a standard solution, too much options or details usually just confuses the end users

@stormi I really appreciate the continued help. I'm not sure it works. On my single-host pool master—the one I want to join into my half-upgraded pool—I run the command: xe host-emergency-disable-tls-verification It returns with no errors. If I do xe host-param-list and look through the parameters for my host, I see: tls-verification-enabled ( RO): false This is the only thing I see documented that can turn off TLS verification. If some other command like pool-uninstall-ca-certificate would have the effect of disabling TLS verification, I can't see that documented anywhere. In fact, even though xe pool-uninstall-ca-certificate appears to be a valid command that my xe binary knows about, I can't find that particular command documented at all. Even after the emergency-disable-tls-verification, if I attempt to join that host to the half-upgraded pool (using xe pool-join...) I get: Error code: POOL_JOINING_HOST_TLS_VERIFICATION_MISMATCH It seems like even though the host has TLS verification off, the fact that its pool has verification enabled is blocking the action.

@MajorP93 throw in multiple garbage collections during snap/desnap of backups on a XOSTOR SR, and these SR scans really get in the way

We'd recently got a relevant experience regarding this weird renaming to uuids. We had one orchestra managing one pool. ISOs were in an ISO SR, with an nfs4 serving it underneath. All fine till then. We added one second pool to the orchestra. Just a single host by itself. One of the very next days we discovered that all names in the ISO SR had been replaced by uuids. Removing/readding the sr to the new pool helped temporarily. Usual names appeared again. But after a few more days, again uuids. Where uuids were appearing, we could not select anything from the dropdown list in the console's cdrom. The list per pool was unpopulated. We tried separate the shares by offering the new pool an nfs4 share from the NAS, actually sharing the same source dir. It did mount but now there was a uuid uniq constraint that was violated, so we could not see no files at all in this new SR. It would not be an illogical thought to have an 'iso sr' attached once to the orchestra and be offered by the orchestra to all managed pools, without uuids, without uniqs etc. There seems to be an unnecessary complication here I think.

No pun, just wait for everyone to get back from our yearly Vates internal event

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

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

Create an appliance with all those VMs and configure the order and delay inside it.

Adding @florent and/or @Bastien-Nollet in the loop

@fred974 It used to be (and probably still is) that You have to be reasonably near correct time for NTP to accept any changes.

@Pilow - so...I powered down the VM and re-attempted the RPU. It seems snapshots is a deterrent for being able to perform a RPU, because I see VMs migrating now so the RPU can run. For specificity - yes, my XCP Hosts are identical (CPU, RAM, etc); there were no affinities set (see screenshot) [image: 1763483116773-cf9b9ae2-5363-4b66-b367-1b0474e54538-image-resized.png] , etc. Thank you for the assist! I think @olivierlambert or his tech writers need to update the RPU requirements area of the docs. Snapshots cannot be present or RPU will fail. Weird why that is

There are no other jobs. I've now spun up a completely separate, fresh install of XCP-ng 8.3 to test the symptoms mentioned in the OP. Steps taken Installed XCP-ng 8.3 Text console over SSH xe host-disable xe host-evacuate (not needed yet of course since it's a brand-new install) yum update Reboot Text console over SSH again Created local ISO SR xe sr-create name-label="Local ISO" type=iso device-config:location=/opt/var/iso_repository device-config:legacy_mode=true content-type=iso cd /opt/var/iso_repository wget # ISO for Ubuntu Server xe sr-scan uuid=07dcbf24-761d-1332-9cd3-d7d67de1aa22 XO Lite New VM Booted from ISO, installed Server Text console to VM over SSH apt update/upgrade installed xe-guest-utilities Installed XO from source (ronivay script) XO Import ISO for Ubuntu Mate New VM Booted from ISO, installed Mate apt update/upgrade xe-guest-utilities New CR backup job Nightly VMs: 1 (Mate) Retention: 15 Full: every 7 Exact same behaviour. After first (full) CR job run, additional (incremental) CR job runs results in one more 'unhealthy VDI'. I've engaged in no other shenanigans. Plain vanilla XCP-ng and XO. There are only two VMs on this host, the XO from source VM, and a desktop OS VM which is the only target of the CR job. There are zero exceptions in SMlog. What do you need to see?