Ping @Team-XO-Backend

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.

Nevermind. I forgot your previous post about: You'll need to modify two files (via SSH): /opt/dell/omc/utilities/tui/bin/ome_disk_config.sh /opt/dell/mcsi/appliance/scripts/appliance_ressource.sh In these files, replace /dev/sd with /dev/xvd. I went and made these changes, and now the Data drive is loading after doing the drive scan. I should mention that doing this BEFORE first logging into the OME web interface and completing the initialization seems to be best (no further errors appear once logged in).

Pinging @Team-OS-Platform-Release

@wgomes yup thanks for bumping this topic, still having the problem too

had the same on one pool that needed 97 updates. RPU was going great, but couldn't migrate VM post-upgrade it is a pool of 2 hosts, second hosts still had 97 patches to pass... even if RPU was finished. we waited 10 min and the 97 patches disappeared, and then we could migrate the VM

Different use cases: Ceph is better with more hosts (at least 6 or 7 minimum) while XOSTOR is better between 3 to 7/8. We might have better Ceph support in the future for large clusters.

@User-cxs peut etre un clnflit IP ou la VM prenait l'IP du master... courage pour la suite !

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.

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

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.

@fnf games If it hangs right after detecting the disk, it could be a bootloader or filesystem inconsistency from the snapshot state. Can you try booting the VM with a recovery ISO to check disk integrity or rebuild the bootloader?

@dlgroep Thank you, we will take thin/thick token into account and use 'claims' part for other properties.

To add a bit more detail on the upgrade path: strictly speaking, you do not need to apply outstanding 8.2 patches before upgrading. When you upgrade to 8.3, you are replacing the entire base system with the 8.3 release which already incorporates everything from the 8.2 patch stream. Any 8.2 patches you hadn't yet applied will simply be superseded. That said, applying them first is still a reasonable approach if you want a clean upgrade history and a fully-patched 8.2 baseline before jumping to 8.3. A few things worth checking before you start on a production pool: Check VM compatibility. Run a quick review of your VMs for any that might have specific OS or toolstack dependencies tied to 8.2. Most guests upgrade cleanly but it is worth knowing your environment. Use rolling pool upgrade if you have more than one host. XCP-ng supports rolling upgrades: you migrate VMs off each host, upgrade it, rejoin the pool, then proceed to the next. This maintains VM availability throughout the process. The XO interface handles this workflow if you have XOA. Back up before the jump. Export critical VM configurations or snapshots beforehand. If you use Xen Orchestra for backups, trigger a manual full backup job before starting. The upgrade itself via yum is straightforward: add the 8.3 repo, yum update, reboot. The toolstack and XAPI will handle pool registration after the host comes back up. After upgrading all hosts, run the post-upgrade checks from the docs (pool metadata sync, storage rescans) and verify HA is healthy if you use it.