Posts made by karlisi

ISO works, installed already on 2 Ubuntu 22.04 VMs

@planedrop To avoid confusion, XOA is paid product, ready to use virtual application. If you installed XO from sources, it's simply XO or XOCE (XO Community Edition). XO components versions you can see in About menu, both xo-server and xo-web. If you want to know how it corresponds to XOA version, see changelog https://github.com/vatesfr/xen-orchestra/blob/master/CHANGELOG.md

@geoffbland said in Xen Orchestra Application XOA Deployment Options/Best Practices.:

What exactly do you mean when you say "XCP-ng small web UI" ? I don't think I have heard of that before?

If you go to http://your.xcp-ng.host.ip you will receive web UI with some links to documentation and to management tools, including Xen Orchestra Virtual Appliance quick deploy wizard

XOA is only the version we (Vates) distribute, not the version from the sources

What is the correct name for the version from the sources then? Is that just called Xen Orchestra?

They are calling community version (from sources) XO and precompiled virtual appliance (paid version) XOA.

@julien-f said in CR tag ignored (kind of) in smart backup:

incomplete VMs should be ignored by smart mode

I believe, XO is using some other way to prevent backup loop.

Thanks again, now CR works as expected!
xo-server 5.64.0
xo-web 5.66.0

@julien-f Thanks!

XO CE, xo-server 5.62.0, xo-web 5.63.0 (doesn't matter, the same was on older versions too)
We have 2 pools (one host XS 7.0.0 in each), cross-pool backups using continuous replication configured on both of them. It means, VMs from pool 1 are replicated to pool 2 and VMs from pool 2 are replicated to pool 1. To avoid replication back, causing loop, we are using exclusions by tag 'Continuous Replication' (default tag XO adds to every replica). Both backup jobs are overlapping in time.
The problem is, some replicas are added to target's backup job and replicating back, despite having 'Continuous Replication' tag. I suspect, that tag is added only after replication is completed, and incomplete VMs are without this tag. This can explain why they are added to backup job. Am I rigt? If so, how can I avoid this? Perhaps this can be considered as XO bug and patched?

@x-rayd said in Backup Continuous Replication hängt!:

This problem have only pool-master node, other node does not have the problem.

Perhaps. I have 2 pools with one node each.

I have the same problem since... I don't remember, a year perhaps. Orphaned snapshots are some way related to continuous replication, they appears randomly sometimes on almost all VMs, sometimes none. For me this is not a problem, I delete them as part of daily routine.
I am using XOCE, xo-server and xo-web 5.59.0.

@tts Are You on latest XOA version?

Stuck CR is a problem with latest XO versions and XO team is working on it.
You can delete incomplete VMs [Importing...] and you should restart XO before start CR jobs again. As workaround some users here made cron jobs to restart XO daily to avoid CR failures.
Automatically deleting incomplete VMs can be dangerous, IMHO. Some of these [Importing..] VMs are properly replicated, I examined few Windows Servers and they are starting and working. So, they can be used as backups.

https://xen-orchestra.com/docs/xoa.html#network-configuration

@olivierlambert Done

@julien-f said in Backup jobs run twice after upgrade to 5.76.2:

@karlisi I've been unable to reproduce the issue so far, can you tell me which version of XO has the issue and which one does not?

Also, if you could provide me with your job configuration it would be nice

Can I send it to you in PM?

Right now one of my CR jobs are stuck, symptoms are the same as with XO from sources.
XOA 5.43.2 (xo-server and xo-web 5.56.2)
Hosts where VM is running and where it is replicated to, both XenServer 7.0
Backup log:

{
  "data": {
    "mode": "delta",
    "reportWhen": "failure"
  },
  "id": "1582750800014",
  "jobId": "b5c85bb9-6ba7-4665-af60-f86a8a21503d",
  "jobName": "web1",
  "message": "backup",
  "scheduleId": "6204a834-1145-4278-9170-63a9fc9d5b2b",
  "start": 1582750800014,
  "status": "pending",
  "tasks": [
    {
      "data": {
        "type": "VM",
        "id": "04430f5e-f0db-72b6-2b73-cc49433a2e14"
      },
      "id": "1582750800016",
      "message": "Starting backup of web1. (b5c85bb9-6ba7-4665-af60-f86a8a21503d)",
      "start": 1582750800016,
      "status": "pending",
      "tasks": [
        {
          "id": "1582750800018",
          "message": "snapshot",
          "start": 1582750800018,
          "status": "success",
          "end": 1582750808307,
          "result": "6e6c19e2-104c-1dcf-a355-563348d5a11f"
        },
        {
          "id": "1582750808314",
          "message": "add metadata to snapshot",
          "start": 1582750808314,
          "status": "success",
          "end": 1582750808325
        },
        {
          "id": "1582750808517",
          "message": "waiting for uptodate snapshot record",
          "start": 1582750808517,
          "status": "success",
          "end": 1582750808729
        },
        {
          "id": "1582750808735",
          "message": "start snapshot export",
          "start": 1582750808735,
          "status": "success",
          "end": 1582750808735
        },
        {
          "data": {
            "id": "4a7d1f0f-4bb6-ff77-58df-67dde7fa98a0",
            "isFull": false,
            "type": "SR"
          },
          "id": "1582750808736",
          "message": "export",
          "start": 1582750808736,
          "status": "pending",
          "tasks": [
            {
              "id": "1582750808751",
              "message": "transfer",
              "start": 1582750808751,
              "status": "pending"
            }
          ]
        }
      ]
    }
  ]
}

Perhaps there is something with my environment but then why it is working with older XO versions.

@tts said in Backup jobs run twice after upgrade to 5.76.2:

Can we import the config from our XO from sources to XOA or should we setup everything from scratch?

Today I got XOA trial ready and imported config from XO-from-sources. Manually started CR jobs are working. Will test it with scheduled CR next couple of days.

@julien-f I have no XOA. I installed XO on top of Ubuntu 18.04 using this script:
https://github.com/Jarli01/xenorchestra_installer
Upgrades are made using another script:
https://github.com/Jarli01/xenorchestra_updater
How to send config to You?

@julien-f said in daily Continuous Replication backup in XO:

node -p '[require("./package").version, require("@xen-orchestra/cron/package").version]'

[ '5.50.1', '1.0.4' ]

The best (or worst), last night after XO restart all backups went without problems. Yesterday I upgraded Ubuntu kernel. And expanded XO disk, because initially it was set too small and there was almost no free space left.

@julien-f What is needed from me to understand what's happening? Today restarted my xo after os updates.

I don't know why, but this is happening only on first schedule after each XO restart. Next schedules are working without issues. Every time this happens, first launch is exactly 1 minute before scheduled time, next launch is in time. I am using XO from sources. This started after I upgraded to xo-server 5.50.1, xo-web 5.50.2.