@bvitnik for example use Pulumi to create DNS records in domains hosted by OVH to point to the dedicated IP of a tenant to publish a spinned up pulumi-docker app in a tenant VM. or use the 1password Pulumi provider to store SSH Keys of deployed VMs of a client our stack is based on PFsense api, but if next datacenter we host in we get a fortinet firewall instead, use the Pulumi provider to manage the network parts in the same Cloudbox app. create on the fly buckets in our Minios to provide dedicated remote for a reseller backup possibilities are quite infinite ?

@bvitnik rhaaaaaa need. will have to dev this.

XOA 5.112.1 and 5.111.1 is fine [image: 1763748852814-7a8824a6-c2d2-4f78-8dda-8eb2a48f70e7-image.png] If I import a new ISO in 53c1a it show the correct name in both 53c1a and d3402

@nuentes said in Booting to Dracut (I trusted ChatGPT): Other things that I didn't mention yet that may or may not be relevent: the enclosure is connected with a USB-C cable to a USB-C input the enclosure hosts 4 disks Other disks/enclosures were not experiencing the disconnect issue The enclosure was actually working fine until a few days after I troubleshot/resolved an issue with one disk having slow transfer speeds. I switched the enclosure from USB-A to USB-C and also disabled spindown for the affected disk in the enclosure. Disabling spindown was done at the VM level, so I didn't mention it above. there is your problem USB is very unreliable for any kind of serious data transfer. Disconnecting devices, data transfer errors, corruptions are just the tip of the iceberg. For anything reliable you have to go for network attached storage or eSATA. I'm that type of a person that verifies md5 sums of all files copied to the USB flash, disk, enclosure etc. I've spotted data corruptions sooooo many times regardless of the OS, version, HW, USB type, storage device type... The only common thing was USB. eSATA and ethernet never produced such corruptions. As far as I'm concerned, USB is for mice and keyboards... and maybe a lamp or fan

@olivierlambert I'd like to see replicated vms in netbox, perhaps not syncing their IP address to avoid conflict DR VM as well

@kevdog Try adding console=ttyS0 earlyprintk=serial,ttyS0. You shouldn't need hvm_serial, xl console should be enough. Make sure that the boot parameters show up correctly in grub.

Hi, I was about to suggest to use backup health check but it seems you'd like to avoid it In this case, I don't really have an answer, maybe @Bastien-Nollet or @florent does.

I haven't had too much difficulty hitting the esc key in time to get into the EFI config. Click the start VM button, quickly click away from the display area and click in the display area, then toggle the esc key until I see it take effect. I know I have a couple running at 1920x1080, but that's actually kind of a pain. I only did that to try and get a larger RDP window, RDP may be limited by the original "monitor" resolution, but this might also be fixed in later updates. This one VM has been up for a few years. (edit, yes this has been changed, VMs with a 4x3 monitor now RDP is whatever I have set).

[edit] I just realized this was from 2024. So far I only have 1 of my 2022 servers changed to the XCP-ng drivers and management agent, the only thing that happened was the NIC went back to DHCP and a short struggle to shift it back to static. I use the e1000 profile when I set up a VM. This was previously using the Xen 9.4.x drivers downloaded from Xenserver. The only other glitch is that if you migrate the VM to another host in the pool, the management agent is no longer detected. But additional migrations and rolling pool updates and reboots are not bothered by this. I'm told this will be fixed in the next version. As far as the drivers themselves, I don't see any issues on this one VM. I think I have another 2022 in my lab with the XCP-ng stuff installed, I'll have to check later. I've had no issues with it. These were both installed from the new Tools ISO that is default with the latest XCP-ng 8.3.x

@Forza I keep hoping to see an Alpha or Beta of XCP-ng 9 soon, but I think there is still a lot of work to be done on the host side and on the Xen Orchestra 6 side.

@k11maris Same on my side. Delta backup for all VMs show this message. [image: 1763710321097-bildschirmfoto-2025-11-21-um-08.30.44.png]

@Pilow Yes, we monitor observability metrics for guest OSes via other means but being able to see this info via the Xen Orchestra web UI along with the other metrics in the Stats tab definitely has is benefits, especially when performing initial troublehshooting or when dealing with groups in our org that only have access to the XO interface and not the other metrics dashboards. Don't get me wrong, I definitely appreciate all of the work that you are all doing to get these tools working and can't wait to start using them in production. I just need to make sure that they work as expected.

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!

I made a fix for this: https://github.com/vatesfr/xen-orchestra/pull/9228 I'm not that familiar with disaster recovery, I'll discuss your point with the team. b-Nollet opened this pull request in vatesfr/xen-orchestra open fix(backups): fix offlineBackup value #9228

@probain No worries, im still learning/improving my ansible/terraform skills aswell

@mguimond Not sure how old your XO is but this is the current Commit. Master, commit 5349f. Suggest try updating and try again. Maybe someone from Vates will have more information.

Ping @Team-Documentation-Knowledge-Management

Hi @jshiells, After some tests, I don't think it can be caused by the load balancer. If the load balancer tries to migrate a VM that is being backed up, the migration instantly fails and nothing happens. Reversely, if a backup job starts when a VM is being migrated by the load balancer, the backup will fail for that VM with error "cannot backup a VM currently being migrated".

@florent Is there anything in the logs he provided that stand out?