@pdonias is working on it (among many other things), I don't know the timeline, but either this or the next release.

@dslauter You can test the new RPMs using the testing repository, FYI: sm-3.2.3-1.14.xcpng8.3 and http-nbd-transfer-1.5.0-1.xcpng8.3.

@encryptblockr Yes, and I documented the process I used a while back here: https://xcp-ng.org/forum/topic/6821/cloud-init-success I just use the stock cloud image .ova file as my base image. for Ubuntu templates. I use the noble (24.04) image in quite a few instances from my template with success. Your post mentions cloud-init is not working - some tips to try troubleshooting, when the new VM is provisioned, (assuming you are able to login) I usually run "cloud-init status --wait" and when that completes I run "cloud-init status --long" for a summary of the state. Then you can grep for WARNING in /var/log/cloud-init.log for clues. If you weren't able to login to the VM - make sure your cloud-init config has the userid's, passwords and SSH keys you will need for login. See the example I posted here, since those are what I use in my lab or some variation. Feel free to share any troubleshooting steps you have taken, and I will help any way I can. I have setup hundreds of VM's from templates using cloud-init so I have seen many of the challenges it brings.

We are implementing tests in our CI to detect this issue and protect against regressions, then we'll investigate the cause.

@mbriet Ever figure this out? I'm getting the same exact thing...

As Mathieu answered in this topic, the bug has been reproduced on our side but isn't trivial to fix. We'll discuss with the team to schedule this task, and we'll keep you informed when it's fixed.

Thanks, this works!

It appears this works on 'Latest' / 5.99.1. We're now going to look at the cluster to see how the cluster is designed via the recipe. Thanks!

Hi @julien-f @olivierlambert , I was actually able to finally figure out what I was doing wrong this whole time! I want to update this thread so that anyone else facing the same issue as me in the future can learn from my mistakes and not waste 10 hours of their weekend because of missing quotation marks. One of the modifications I tried over the weekend was to cat the two files in my command, but this failed : xo-cli vm.create bootAfterCreate=true cloudConfig=$(cat /root/user.yaml) networkConfig=$(cat /root/network.yaml) clone=true name_label="Test VM" template=0856a8d6-9183-f39d-f968-290b18a1bd42 VIFs='json:[{"network":"ca96456f-3843-26f5-7075-1e54f70d8f97"}]' hvmBootFirmware=bios copyHostBiosStrings=true ✖ Error: invalid arg: hostname: at file:///opt/xo/xo-builds/xen-orchestra-202410090754/packages/xo-cli/index.mjs:189:13 at arrayEach (/opt/xo/xo-builds/xen-orchestra-202410090754/node_modules/lodash/_arrayEach.js:15:9) at forEach (/opt/xo/xo-builds/xen-orchestra-202410090754/node_modules/lodash/forEach.js:38:10) at parseParameters (file:///opt/xo/xo-builds/xen-orchestra-202410090754/packages/xo-cli/index.mjs:186:3) at Object.call (file:///opt/xo/xo-builds/xen-orchestra-202410090754/packages/xo-cli/index.mjs:612:18) at main (file:///opt/xo/xo-builds/xen-orchestra-202410090754/packages/xo-cli/index.mjs:437:32) at file:///opt/xo/xo-builds/xen-orchestra-202410090754/packages/xo-cli/index.mjs:668:1 at ModuleJob.run (node:internal/modules/esm/module_job:234:25) at async ModuleLoader.import (node:internal/modules/esm/loader:473:24) at async asyncRunEntryPointWithESMLoader (node:internal/modules/run_main:123:5) I realized just now that I completely forgot to try putting the variables in quotes, and this one simple tweak has allowed me to successfully spin up the VM with all of the correct cloud-init configurations applied xo-cli vm.create bootAfterCreate=true cloudConfig="$(cat /root/user.yaml)" networkConfig="$(cat /root/network.yaml)" clone=true name_label="Test VM" template=0856a8d6-9183-f39d-f968-290b18a1bd42 VIFs='json:[{"network":"ca96456f-3843-26f5-7075-1e54f70d8f97"}]' hvmBootFirmware=bios copyHostBiosStrings=true 166b36b4-04a6-4dfa-b413-591dbd87195b Thanks again for all of your help guys!

@Greg_E yeah I can imagine, I dont think the ram does much except gives you some "margins" under some heavier load. With 12 VM's I wouldn't bother increasing it from the default values Yea the mgmt interface in ESXi is nice, I think the standalone interface is almost better than vCenter. Im pretty sure XO Lite will be able to do more when it is done, for example you'll be able to manage a small pool with it.

Worth creating a GH XO issue with most details as possible

That's correct

I re-ran everything using the latest 22.04 Ubuntu ISO instead of 20.04. Hostname templating is now working properly. Must have read too fast the first time when I went for 20.04. There must be some critical difference between the cloud init or distribution versions that caused my issue.

@olivierlambert I created the issue on GithHub. https://github.com/vatesfr/xen-orchestra/issues/7884 MrGrymReaper created this issue in vatesfr/xen-orchestra open xo-server fix: Update acme-client npm and introduce support for External Account Binding (EAB) #7884

@runevn A bit more from my 'troubleshooting notes' I gathered back when I was prototyping a lot of very complex configurations and worked with Chad Smith: Test user-data rendering: cloud-init query --format "$(sudo cloud-init query userdata)" Test jinja template rendering: cloud-init query --format="$( cat test.cfg )" # test.cfg would be the test cloud-config.cfg file to render Test jinja template detailed: cloud-init devel render test.cfg -d Query metadata: cloud-init query -f {{v1.distro}} ========= Debug user-data rendering ============= cloud-init devel render /var/lib/cloud/instance/user-data.txt -d Check actual seed file from provider cloud-init devel render /var/lib/cloud/seed/nocloud-net/user-data -d On a system where cloud-config wasn't honored, run: sudo cloud-init query --system # or you can add --annotate which will annotate the specific lines where an error is in the #cloud-config YAML per Chad Smith; All cloud-init instance data /var/lib/cloud/instance/ Userdata /var/lib/cloud/instance/user-data.txt Datasource /var/lib/cloud/instance/datasource metadata /run/cloud-init/instance-data.json Seed files from provider/hypervisor: /var/lib/cloud/seed/nocloud-net For anyone doing a deep dive into troubleshooting cloud-init configuration rendering.

@jshiells Why don't you open a support ticket and allow us to take a look at this for you?

Oh wow, that was fast! Thank you very much, I will check internally to be sure it will be reviewed soon