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

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

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

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.

Because doing an update without rebooting doesn't reload the updated main programs, like XAPI. A host in only updated after a full reboot.

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.

Yes!! Congrats for everyone (including you for the feedback @dcskinner !)

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.

@nikade This is not related to Dom0 RAM. It's related to the host RAM.

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

@Pilow error reporting is a feature in itself . Thanks

@Bastien-Nollet Great, thanks!

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