Hi @Pilow, Thanks for the report. We are aware that there are many problems with the FLR. We would like to fix them but they are not easy to fix, and we can't give an estimation date for a fix. I've linked this topic to our investigation ticket. For the moment, when FLR fails, we recommend to manually restore your files by following this documentation: https://github.com/vatesfr/xen-orchestra/blob/master/%40vates/fuse-vhd/README.md#restore-a-file-from-a-vhd-using-fuse-vhd-cli

@omatsei said: @omatsei I figured out the problem. There appears to be a bug in XO that requires you to check "Check Certificate" and/or "Start TLS", save the configuration, then uncheck them, then save again. Then it should work. The bug is that they're unchecked by default, but apparently they're enabled in the background. Thanks for that, I was stump on this one trying to reconfigure a new instance. This is defintely the case even with the latest auth-ldap (v0.10.11) plugin.

If you're looking for a quick way to verify those files without running a full restoration test every single time, you can usually run a checksum comparison (MD5 or SHA256) against the original data. For a more 'point and click' approach to double-check specific files or verify hashes quickly, I've used https://thetoolapp.com/utilities/file-integrity-checker/ before. It’s pretty handy for a quick integrity check if you aren't in the mood to mess around with the command line for every single backup set.

For my reference later. wget http://downloads.hpe.com/pub/softlib2/software1/pubsw-linux/p1257348637/v76502/hpacucli-9.20-9.0.x86_64.rpm yum install -y --nogpgcheck hpacucli-9.20-9.0.x86_64.rpm hpacucli controller slot=0 physicaldrive all show

Replying to an old thread because this one popped up in a search. There is an open source and locally running ignition/combustion generator that I've used on bare metal. To use it with XCP-ng, we would need the ability to have a second "cd rom" drive during the install phase, one for the OS installer, one for the combustion/ignition ISO generated from the tool. https://opensuse.github.io/fuel-ignition/ They say it only runs locally, no info is send out to the web. I didn't monitor my connection on the one time I used it, and probably won't the next time (coming soon to a bare metal cluster in my lab). For the record, I'm using the LEAP version of Micro for my tasks.

@TheNorthernLight Thanks for pointing that out, that totally makes sense, I should have realized to look it up that way. I guess I just think of XCP-ng as its own product so much that I forget it's based on Xen even though I know that.

@geometry game 2 This usually happens when dependencies are out of sync after pulling updates. Did you try removing node_modules and the lock file and then running yarn install again before starting XO?

@simonp - Can you reshare the dashboards. The link says json is not available for any of these dashboards,

La remarque a été intégrée dans l'article: https://www.myprivatelab.tech/xcp_lab_v2_ha#perte-master Merci encore pour le retour.

I've seen this happen after a BIOS update or if a CMOS battery starts failing. Sometimes the motherboard resets to 'Legacy' instead of 'UEFI' (or vice versa), and GRUB just loses its mind because it can't find the partition it expects. It’s worth a quick check in your firmware settings to make sure the boot mode and the drive order haven't shifted on you.

That is a frustrating loop to be in, especially with TrueNAS. Usually, when the VM fails to start after a change, it’s because XCP-ng is trying to pass through a PCI device (like an HBA) that isn't being released properly by the host. Have you checked if the "hide" parameters in your grub config are still correct? Sometimes an update can reset those, and the host grabs the controller before the VM can. Another thing to try is toggling the BIOS/UEFI mode in the VM settings - TrueNAS can be picky about that depending on which version you’re running.