@lover said in XOSTOR hyperconvergence preview:
Anyone else getting a 301 error?
http://mirrors.xcp-ng.org/8/8.2/base/x86_64/repodata/repomd.xml: [Errno 14] HTTPS Error 301 - Moved Permanently Trying other mirror.
301 is not an error (as a failure) it's a redirect. Here it redirects correctly to a mirror nearby. In my case: https://mirror.uepg.br/xcp-ng/8/8.2/base/x86_64/repodata/repomd.xml
@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".
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?
@Cyrille said in How to deploy the new k8s on latest XOA 5.106?:
@ferrao Thank you for the logs, with it I was able to reproduce the bug.
It's at the end of the recipe, when the tag associated with the k8s cluster is saved in the user's custom filters. This has no effect on the cluster creation, as this is done at the end when everything else is done.
To avoid this bug in future runs, you can save a custom filter from the search field in the VMs list.
About the first error you encounter, it's related to the template used to create the VM, which seems not available at the VM creation... I'm working on this to understand why.
I think I was able to nail down the first one as a DHCP server with insufficient leases for all VMs. Because when I used static IP addresses I was able to generate the second log.
I'll try to create the tag you mentioned now and redeploy everything from scratch. Is there any specific text tag that I should create? I'm not sure if I understand 100% the procedure.
I'm trying to deploy the updated k8s cluster on XOA 5.106 but it fails quietly.
After digging through the logs I was able to find this:
{
"id": "0ma67t63q",
"properties": {
"method": "xoa.recipe.createKubernetesCluster",
"params": {
"clusterName": "VersatusHPC",
"controlPlanePoolSize": 3,
"k8sVersion": "1.33",
"nbNodes": 3,
"network": "4751905f-b4db-2d54-d05d-0c1be97a0260",
"sr": "f2d0eb72-4016-4b3b-8dc0-bc2a16df6c35",
"sshKey": "ssh-ed25519 AAAAC3NzaC1lZDI"
},
"name": "API call: xoa.recipe.createKubernetesCluster",
"userId": "fd28fb18-c3f1-429b-919f-4e8ae57dde0e",
"type": "api.call"
},
"start": 1746155348774,
"status": "failure",
"updatedAt": 1746155466728,
"end": 1746155466728,
"result": {
"code": 10,
"data": {
"errors": [
{
"instancePath": "",
"schemaPath": "#/required",
"keyword": "required",
"params": {
"missingProperty": "template"
},
"message": "must have required property 'template'"
}
]
},
"message": "invalid parameters",
"name": "XoError",
"stack": "XoError: invalid parameters\n at Module.invalidParameters (/usr/local/lib/node_modules/xo-server/node_modules/xo-common/src/api-errors.js:21:32)\n at Xo.call (file:///usr/local/lib/node_modules/xo-server/src/xo-mixins/api.mjs:121:22)\n at Api.#callApiMethod (file:///usr/local/lib/node_modules/xo-server/src/xo-mixins/api.mjs:409:19)\n at Xoa.createCluster (/usr/local/lib/node_modules/xo-server-xoa/src/recipes/kubernetes-cluster.js:262:28)\n at Task.runInside (/usr/local/lib/node_modules/xo-server/node_modules/@vates/task/index.js:175:22)\n at Task.run (/usr/local/lib/node_modules/xo-server/node_modules/@vates/task/index.js:159:20)\n at Api.#callApiMethod (file:///usr/local/lib/node_modules/xo-server/src/xo-mixins/api.mjs:469:18)"
}
}
However that wasn't that helpful.
I tried changing options and atributes and got a little further but it ended up with a similar issue:
{
"id": "0ma78aljw",
"properties": {
"method": "xoa.recipe.createKubernetesCluster",
"params": {
"clusterName": "VersatusHPC",
"controlPlaneIpAddresses": [
"10.20.0.151/24",
"10.20.0.152/24",
"10.20.0.153/24"
],
"controlPlanePoolSize": 3,
"gatewayIpAddress": "10.20.0.1",
"k8sVersion": "1.33",
"nameservers": [
"10.20.0.1"
],
"nbNodes": 3,
"network": "a28fd0a8-70e2-8fc6-cefa-12c46c8f47cb",
"searches": [
"local.versatushpc.com.br",
"versatushpc.com.br"
],
"sr": "f2d0eb72-4016-4b3b-8dc0-bc2a16df6c35",
"sshKey": "ssh-ed25519 AAAAC3NzaC1lZDI1N",
"vipAddress": "10.20.0.150/24",
"workerNodeIpAddresses": [
"10.20.0.154/24",
"10.20.0.155/24",
"10.20.0.156/24"
]
},
"name": "API call: xoa.recipe.createKubernetesCluster",
"userId": "fd28fb18-c3f1-429b-919f-4e8ae57dde0e",
"type": "api.call"
},
"start": 1746216628124,
"status": "failure",
"updatedAt": 1746217416799,
"end": 1746217416798,
"result": {
"message": "Cannot read properties of undefined (reading 'VM')",
"name": "TypeError",
"stack": "TypeError: Cannot read properties of undefined (reading 'VM')\n at Xoa.createCluster (/usr/local/lib/node_modules/xo-server-xoa/src/recipes/kubernetes-cluster.js:488:22)\n at Task.runInside (/usr/local/lib/node_modules/xo-server/node_modules/@vates/task/index.js:175:22)\n at Task.run (/usr/local/lib/node_modules/xo-server/node_modules/@vates/task/index.js:159:20)\n at Api.#callApiMethod (file:///usr/local/lib/node_modules/xo-server/src/xo-mixins/api.mjs:469:18)"
}
}
I can see 3 control planes and 3 works were deployed. However it does not complete the task.
What steps I further need to take to investigate the issue?
Thanks.
@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) --
This is what it will look like if the license hasn't been activated --
Oh man...
That's a new thing? You're totally right.
It's now working correctly again.
@Danp said in XOA fails after update to 5.106.0:
@ferrao Make sure that you've activated the trial license under the XOA > Licenses tab.
Yes, it is. I was testing the User Portal on April 28th. Received the e-mail message regarding the Micro K8s and tried updating to give it a try.
Now XOA is locked with this message.
@Danp said in XOA fails after update to 5.106.0:
Hi @ferrao,
This is with XOA Free, correct? Have you tried switching to the Stable release channel?
Dan
It's on trial mode. So I think it can be considered paid.
@Danp we are also with the license has expired message:
Your current Xen Orchestra license has expired (Dec 31, 1969). Please reach out to your vendor.
Looks like something related to Unix time bug? Something may be set to zero or undefined.
@lover said in XOSTOR hyperconvergence preview:
Anyone else getting a 301 error?
http://mirrors.xcp-ng.org/8/8.2/base/x86_64/repodata/repomd.xml: [Errno 14] HTTPS Error 301 - Moved Permanently Trying other mirror.
301 is not an error (as a failure) it's a redirect. Here it redirects correctly to a mirror nearby. In my case: https://mirror.uepg.br/xcp-ng/8/8.2/base/x86_64/repodata/repomd.xml
@ronan-a thanks. I've deployed it already with the script on the first post. Seems to be working. I've opted to used redundancy=3 in a 3 hosts setup. It's a lot of 'wasted' resources but seems to be the best option for performance and reliability.
May I ask now a licensing issue: if we upgrade to Vates VM, does the deployment mode on the first message is considered supported or everything will need to be done again from XOA?
Thanks.
@ronan-a and @Maelstrom96 I didn't get this hostname issue.
Does XOSTOR needs a fully functional DNS setup to work? Or the failure was local due to the local change of the hostname?
I didn't understand if the communication is done by IP addresses directly or if DNS name resolution is needed.
I'm particularly interested in this because with XOSTOR I'm considering virtualizing my pfSense firewall directly and get rid of the physical servers. And in this scenario in a case of a entire pool reboot I must guarantee that I will have the two pfSense VMs up and running, with the option to auto start after reboot, so I can access the entire infrastructure or else I'll be locked from outside.
