@Kajetan321 Your disk image is presented as a block device to the VM. This is done by a kernel module called blktap and its userspace part tapdisk.

You are seeing dom0's kernel messages when these block devices are attached by blktap. It's just an informational message.

@andrewperry The release notes warn about PV guests.

In any case, you can ignore it.

@Kajetan321 You should consider the effects of NUMA/vNUMA in terms of performance. Crossing over to other physical CPUs or memory banks will create slowdowns.
If possible, unless you absolutely need all those VCPUs on any or both VMs, you may be best off splitting the 36 VCPUs and assigning 18 on each VM, checking to see if all the memory stays with the bank(s) of those specific VCPUs. See my articles on the CUCG site about NUMA and in particular, graphics performance (and of course, calculations will also be affected). Best would be to
run benchmarks with both configurations. Shrinking the number of VCPUs on a running VM can lead to issues (as indicated in the video posted just before my response).
See the Tale of Two Servers articles here for details: https://community.citrix.com/profile/46909-tobias-kreidl/#=

Pinging @florent about this

Ghost XO user authentication task has nothing to do with backup restore, it is a known bug that will likely be fixed in the next release.

Hrm, I've always just reattached to the backup repo so I could see everything. Must've been a misunderstanding on my part.

That's what I meant. Even a fresh XO without any previous config could restore backup if you add the backup repository at the same path where you had your backups before 🙂

Sure, it's even easier to restore XO metadata because you don't have to remember where are you backups, but still, worst case scenario (losing everything except the BR), it's possible to restore.

I am using USB-servers from SEH and Silex. Both of them are working.

Silex can provide higher Performance - SEH is IMHO nicer for license-dongels, etc.

It's important to understand the components you are using, especially on a software that you use without support/training 🙂

In short:

SR: a Storage Repository is access by your host/dom0/XCP-ng, and will be used to store ISOs and/or VM disks. It's running on a relatively old CentOS release (7.x), and will mount with some specific settings BR/remote: a Backup Repository where Xen Orchestra will send the backup of your VMs. Usually, Xen Orchestra runs (in XOA) inside a Debian 11 VM, with default NFS mount options (default: ie from the operating system point of view).

It's hard to tell exactly the issue since you are likely using XO from the sources, so a XO that you choose to install on a system where we (aka "XO devs") have precisely 0 control on. Plus the NFS configuration part is also out our scope because it's not running inside our infrastructure too.

That's a lot of moving pieces, that's why it's important to understand what you do so we can assist here the most efficient way we can 🙂

@Kajetan321 No static memory would be 28G/28G 8/28 is dynamic memory

@olivierlambert Thank you for following up.

@olivierlambert Yes, each job has a unique identifier and willl not touch backup files of other jobs.

@stormi Yeah, seems better this way ^^

I will try to write a draft in the next few days to update the documentation 🙂

Sadly, it's hard to know what happened without getting the errors you had (eg when you tell: "VM will not start" is very vague).

@Darkbeldin Got ya, thanks!

@olivierlambert Thanks!