@Cyrille said in How to deploy the new k8s on latest XOA 5.106?: @ferrao open the VMs list (Home>VMs), click on "Filters" near the search bar, and then click "Save...", in the popup dialog enter a name for the filter and click "OK". [image: 1746456413368-snapshot_2025-05-05_16-41-58.png] This should be enough to workaround the 2nd bug that happened at the end (that prevent to save the tag that is added to the clusters VMs) Hello. Thanks, it seems to have worked. The deployment screen no longer hangs. However I don't get any feedback at the finish. And on the Task log, the log about the Kubernetes cluster seems to be gone: Cannot GET /rest/v0/tasks/0mabaot5t I've selected this task: API call: xoa.recipe.createKubernetesCluster 2025-05-05 13:28 Is this expected?

Ping @pdonias

@piotrlotr1 I think my original mini-lab did this, I had mistakenly joined these hosts to the big lab pool, found out is was wrong and detached them to make a mini-lab pool. There were some oddities when I did this, but I just worked past them and created their own pool and did my warm migrations. Wish I had taken better notes of this when I did it. I wiped and rebuilt my mini-lab now, so no going back.

Thanks for fixing this!

@Bastien-Nollet Thanks for the update. In my community edition instance at my church, I just updated it to Master, commit 37fbb so I'll test over the weekend and provide an update. For my XOA (Airgapped) instance at work, I did receive an updated appliance about two weeks ago, so I'll test and see if the problem persists. If it does, then I'll just wait until the official release of XO and then I'll request an updated appliance.

Problem solved with update of XOCE

@onthegrid Sure! So with the network config above. Gotta make your own MAC address and have it match the one in the interface field when cloning the template. (Variable would be nice here.) Cloud config in XO: [image: 1740157949649-55ba86a2-e4cb-4d8a-b3b3-904d1bb1fa38-image.png] Installed cloudbase with defaults. Did not run sysprep. Did not reboot. I plan to handle those IDs later. And trying to sysprep Windows 11 didn't work/broke. Cloudbase-init.conf: [image: 1740157825385-6f8df03b-510f-48e5-9c0a-a42de0593eef-image.png] If i recall correctly, it was just the last three lines I changed/added. Tested on Server 2022 and Windows 11. If we do go into produciton on this platform, I'll do the other config stuff later. I just wanted to make sure I could get the OS config'd with an IP, update the hostname, and reset the administrator password.

@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.

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

@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!