@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

Yay!

@Danp That would appear to be it, thanks for pointing it out. Should have really spotted it myself of course!

So the first KB article helped from Vates so thank you again @Danp . What else I found was that in the VMKernel NIC's that the only service enable was management. [image: 1719252207996-15468340-bb46-46ca-9b8d-3fa8aa9b1087-screenshot-2024-06-24-at-2.02.51-pm.png] I enabled the other options that I could without a license, and everything worked as expected! Yay! Thanks!

@Bastien-Nollet Thank you, great explanation!