@olivierlambert Thanks for the clarification, it is definitely from sources. Apologies I will try to remember!
I'll patch my system a little later today.
Edit: Patched to Xen Orchestra, commit 6953e - All good.
Thanks, really appreciate the prompt fix!
I'm getting similar too, I get the "entries must be sorted in asc order 2025-01 2025-52" error (see below) hope that's helpful.
Based on the comment about removing the Long-term retention of backups data, I just removed the Number of weekly backups kept entry and re-ran, this allowed the backup to run. I kept my Number of daily backups kept limit which I haven't reached yet.
"message": "backup VM",
"start": 1735640611472,
"status": "failure",
"tasks": [
{
"id": "1735640611748",
"message": "snapshot",
"start": 1735640611748,
"status": "success",
"end": 1735640616464,
"result": "1f91db46-fbfe-ba09-9f8b-1c350d7493fd"
},
{
"data": {
"id": "59e1ac20-f03d-45b4-953d-6fb7277537c2",
"type": "remote",
"isFull": true
},
"id": "1735640616501",
"message": "export",
"start": 1735640616501,
"status": "failure",
"end": 1735640616505,
"result": {
"generatedMessage": false,
"code": "ERR_ASSERTION",
"actual": false,
"expected": true,
"operator": "strictEqual",
"message": "entries must be sorted in asc order 2025-01 2025-52",
"name": "AssertionError",
"stack": "AssertionError [ERR_ASSERTION]: entries must be sorted in asc order 2025-01 2025-52\n at getOldEntries (file:///home/root/xen-orchestra/@xen-orchestra/backups/_getOldEntries.mjs:116:18)\n at FullRemoteWriter._run (file:///home/root/xen-orchestra/@xen-orchestra/backups/_runners/_writers/FullRemoteWriter.mjs:39:24)\n at process.processTicksAndRejections (node:internal/process/task_queues:95:5)\n at async FullRemoteWriter.run (file:///home/root/xen-orchestra/@xen-orchestra/backups/_runners/_writers/_AbstractFullWriter.mjs:6:14)"
}
@ddelnano Sorry to drag this up and also no OP, but I'm just looking at how to set a static RAM allocation via terraform too so this would be relevant to me.
Here's a snippet of code, it's using a generic Ubuntu 22.04 LTS cloud image template which has 1GB ram by default, in the code I set the memory to 4GB, which works but uses Dynamic rather than static
resource "xenorchestra_vm" "bar" {
name_label = "TerraformCreatedMe"
name_description = "Terraform Managed"
template = data.xenorchestra_template.ubuntu22.id
memory_max = 4294967296
cpus = 4
destroy_cloud_config_vdi_after_boot = true
hvm_boot_firmware = "uefi"
From the hypervisor side the VM looks like this:
memory-static-max ( RW): 4294967296
memory-dynamic-max ( RW): 4294967296
memory-dynamic-min ( RW): 1073741824
memory-static-min ( RW): 1073741824
So to me it looks like memory_max in terraform changes just memory-static-max and memory-dynamic-max which leaves the VM with dynamic memory control.
I want the behaviour to be, when I create a new VM or change the RAM allocation for the VM to have static RAM not dynamic. I hope this is possible.
@ronan-a I think it would be a really useful option, hopefully we'll see it in the future. Thanks again for taking the time to answer my questions.
@ronan-a Thanks for taking the time to explain, it is appreciated. I will have a further read to help my understanding more.
Do you know if it is possible to add multiple XOSTOR SRs so that I have the option of separating disk types e.g. one XOSTOR for NVMe SSD and one for SATA SSD?
Set up a two node cluster, hv-01 & hv-02, created a VM.
With the VM on hv-01
hv-01 shows:
xcp-volume-a5fd7961-af4c-47ed-a24b-99d432330107 role:Primary
disk:UpToDate
hv-02 role:Secondary
peer-disk:UpToDate
hv-02 shows:
xcp-volume-a5fd7961-af4c-47ed-a24b-99d432330107 role:Secondary
disk:UpToDate
hv-01 role:Primary
peer-disk:UpToDate
Migrated VM to hv-02
hv-01 shows:
xcp-volume-a5fd7961-af4c-47ed-a24b-99d432330107 role:Secondary
disk:UpToDate
hv-02 role:Primary
peer-disk:UpToDate
hv-02 shows:
xcp-volume-a5fd7961-af4c-47ed-a24b-99d432330107 role:Primary
disk:UpToDate
hv-01 role:Secondary
peer-disk:UpToDate
It looks like the VMs disk is automagically assigned primary to it's local node, mind blown! Am I reading this right?
This looks really cool, I'm looking forward to testing it. A quick question...
I was wondering in a two node system if there is performance benefit to VMs hosted on a node where the DRBD volume is master and if so can I have multiple XOSTOR volumes using separate disks on each nodes e.g. linstor_group1 / linstor_group 2 where node1 is primary for linstor_group1 and node2 is primary for linstor_group2?
In this case I could organise VM home servers according to where their DRDB master is.
So I guess the questions are:
Thanks
@olivierlambert Thanks for the clarification, it is definitely from sources. Apologies I will try to remember!
I'll patch my system a little later today.
Edit: Patched to Xen Orchestra, commit 6953e - All good.
Thanks, really appreciate the prompt fix!
@pdonias Thanks, I'm happy to patch my XOA when you're ready and let you know how I get on.
Hi,
We are experiencing problems logging into XOA (from sources) via Google Auth after a recent update:
From
Xen Orchestra, commit 996ab
to
Xen Orchestra, commit 60434
We can see that the Google Auth plug-in has gone from v0.2.2 to v0.3.0, the issue was noticed only after a reboot. The browser error is a simple Internal Server Error, and the log shows only xo-server[1053]: Cannot read properties of undefined (reading 'id').
I can log in with a local (non Google Auth) user.
Has anyone else experience this and/or have any troubleshooting suggestions?
Thanks
Thanks @olivierlambert
I changed the release channel to 'latest' and updated to xo-server 5.64.1
/ xo-web 5.67.0
Both now report as being PVHVM with the additional "Management agent 7.2 detected" / "Management agent not detected"
Thanks