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.

Ping @Team-XO-Backend

@DustinB thank you! I suspected as much, but as my wife points out all the time, I am terrible at finding things, so I figured I would ask.

Still working fine But after this work You put in it seems like VDI-size in VMs VDIS is back to showing size of snapshot instead of size of VM. I'l update the XO6 thread https://xcp-ng.org/forum/topic/11604/xo-6-dedicated-thread-for-all-your-feedback/169

@jerry1333 could you do a TOP in XOA vm to identify what consumes CPU ?

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?

I haven't found how to set up a physical NIC. you can only edit already configured ones.

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

Support tunnel is active but I have troubles to access support "Oops, something went wrong! Don't worry, our team is already on it". I'll keep trying, thanks.

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.

@florent I can confirm that this fixes the issue!

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

Adding @Team-XO-Backend in the loop

@Pilow The backups kept by LTR are just regular backups with a specific tag, which doesn't change how we treat them. If you want to avoid each of your LTR backup to depend on one another, we recommend to set a full backup interval value to your backup job, which will regularly force a full backup. (even without LTR, having an infinite chain of backups can cause problem in the long term, especially if no healthchecks are made)