@olivierlambert @webminster It's in the backlog, we'll try to plan it for March or April. We're also open to external contributions if anyone wants to give it a try

@Andrew To me the summary answer is no, ha. The content of this system is nothing super important. So replacing it new would be the quicker approach.

@ph7 I still appreciate your contribution, nonetheless. I have reached out to support for assistance with the latest build, so we'll see how that goes.

@ecoutinho Thanks for chiming in. I managed to figure out the math, but thanks nonetheless.

@olivierlambert Bringing this back up because I'm thinking of retiring old servers in exchange for new mini-PC. Looking around in XO, I don't see anywhere to click to promote a server in a pool to controller (master), am I missing something? My plan would be to join all new mini-pc to the existing pool, migrate VMs to these new servers, then take controller (master) onto one of the mini-pc. After that I would remove the older servers from the pool and shut them down. Is the proper way to use the above command, or go to the local console and just force promote one of the new mini-pc to be the new controller? [edit] found it, been a while since I've set up a pool. Click where the arrow is and you get choices on which server in the pool you want to control things. [image: 1737994794797-xcp_commander.png]

@Danp It used to be 45 seconds to a minute before, but good to know thank you. I updated my origional reply with the updated information. Thank you for for the help

@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