Edit to my previous post: the script is checking for working DNS, so i cannot pre-setup network. If you want the fixed applicance with the drivers installed, ping me ! To setup the network, you just need to login (root/changeme, yeah the password is... bleh), and launch the script /usr/local/brs/puppet/scripts/install.sh -lui

@ph7 Well, why does the test email from the plugin config work just fine? Doesn't make any sense. Anyway changed to Protonmail smtp server, so will see how this goes.

Ping @pdonias

DR (so full replication) and not CR (incremental replication), right? In DR, have you enabled compression? If yes, try to disable it If not tested, try in CR

Great news Closing this as fixed. Thanks everyone for your feedback!

Reping @dthenot

@olivierlambert Noted on another improvment for the next roadmap

@Danp said in XOA fails after update to 5.106.0: @ferrao Prior to the latest release, the trial worked without actually activating the license on the XOA > Licenses tab. Double check that the license is activated (should look like this) -- [image: 1746139916552-d905469d-2f34-485e-bb8e-61e388faa430-image.png] This is what it will look like if the license hasn't been activated -- [image: 1746140018468-b08a2fff-939f-40af-832e-f50d020e8817-image.png] Oh man... That's a new thing? You're totally right. It's now working correctly again.

Hi, I'm pretty sure this is planned to be addressed in XO6. Dan

Working well for me on XCP 8.3. Thanks for all your hard work on this!

Hello, I suggest you look also for Packer to build ready to use VM templates, with cloud-init, guest tools, and the softwares you'd need. There's a blog post for this https://xcp-ng.org/blog/2024/02/22/using-packer-with-xcp-ng/.

@Cyrille said in Kubernetes Recipe: @abreaux said in Kubernetes Recipe: Is there any way to get the cloud-init used in the Hub Kubernetes recipe? Looking to customize the deployment using Terraform and I want to make sure I include all the same tasks. What do you want to do actually? Do you want to "edit" a VM that has been deployed with the recipe (1), or do you want to deploy a new cluster that will copy the hub recipe (2)? In case of (1), you can find the cloud-init content inside the VM itself: /var/lib/cloud/instance/cloud-config.txt In the case of (2), the current version (5.105) of the k8s recipe is not really stable and is not intended to be used with Terraform. I can only recommend to find another solution (you can find some examples in the DevOps mega thread, like using Rancher). In the next release of XOA, we have updated the Kubernetes recipe to use MicroK8s, which provides a light, open-source, scalable and production-ready Kubernetes distribution. Actually, I didn't realize it was on the VM after deployment, so #1 is fine.

@olivierlambert, Why would this issue be related to my NFS share? I can access the share without any problems, read and write operations work fine. Other NFS shares with multiple applications running are also functioning normally. I checked the XO logs and found the following: xo-server[679]: 2025-04-29T21:45:58.276Z xo:api WARN | backupNg.listFiles(...) [114ms] =!> Error: Command failed: vgchange -ay vg_iredmail xo-server[679]: File descriptor 22 (/var/lib/xo-server/data/leveldb/LOG) leaked on vgchange invocation. Parent PID 679: node xo-server[679]: File descriptor 24 (/var/lib/xo-server/data/leveldb/LOCK) leaked on vgchange invocation. Parent PID 679: node xo-server[679]: File descriptor 25 (/dev/fuse) leaked on vgchange invocation. Parent PID 679: node xo-server[679]: File descriptor 26 (/var/lib/xo-server/data/leveldb/MANIFEST-000103) leaked on vgchange invocation. Parent PID 679: node xo-server[679]: File descriptor 31 (/dev/fuse) leaked on vgchange invocation. Parent PID 679: node xo-server[679]: File descriptor 34 (/var/lib/xo-server/data/leveldb/000356.log) leaked on vgchange invocation. Parent PID 679: node xo-server[679]: WARNING: Couldn't find device with uuid oWTE8A-LNny-Ifsc-Jmtp-lTkB-dSjt-2AqhwY. xo-server[679]: WARNING: VG vg_iredmail is missing PV oWTE8A-LNny-Ifsc-Jmtp-lTkB-dSjt-2AqhwY (last written to /dev/xvda4). xo-server[679]: Refusing activation of partial LV vg_iredmail/lv_root. Use '--activationmode partial' to override. To me, this looks more like an issue with file restore than the NFS itself. It seems similar to what's reported here: https://github.com/vatesfr/xen-orchestra/issues/7029 andrew64k created this issue in vatesfr/xen-orchestra open File level restoration not working on LVM partition #7029

@gduperrey Ok, thank you. Appreciate the explanation.

@olivierlambert nice catch It's following a dependencies update, removing an old one ( node-fetch ) . The fix should be merged this morning ( with the ability to resume an import ) https://github.com/vatesfr/xen-orchestra/pull/8440 fbeauchamp opened this pull request in vatesfr/xen-orchestra closed feat(v2v): resume an incomplete import #8440

@irtaza9 I have the main characteristics of such a temple: Minimal install is the basis root fs: ext4 and minimum 10G disk IP: DHCP ssh login: cloud-user login, ssh public key only. If you are interested I can make it available for download.

@blackliner Honestly I never had this use case, but I would imagine terraform has a feature for this. I'll look into it, it's got me curious

@McHenry hello, thanks for the report. Can you open a suggestion on Github so we can plan it or next roadmap? Have a good day.

Could you please provide the output of (for the master and the candidate host): xe host-list params=software-version It does seem odd....