@Forza
I started experimenting with this function in dec -24 and have run it in "production" in my homelab since jan -25
I suggest You keep the Backup retension (52) to 1.
this is my setup
[image: 1762170193505-e080cadf-7ad0-48e1-aac5-72bfbec88900-image.png]
Sequence
[image: 1762171293182-9a7ab8d6-057a-459e-b026-657580a47116-image.png]
Schedules
[image: 1762171204769-541c3859-b8bf-4230-bc49-871d1fdc0897-image.png]
And this is the result from one of my VMs
[image: 1762170304133-da4b3ef8-3abc-4663-b287-d87cbe98f152-image.png]
[image: 1762170378949-e1040285-6f50-42c3-af90-052774bc8ecf-image.png]
As You can see all the backups from jan - apr and most of may are removed
I am waiting to see what will happen when we go into 2026, If I remember correctly,there was some bug at 2024 -> 2025 but hopefully I get my first yearly backup
@rkelley You nailed it for item 2. Was driving me crazy!
Ok, that does make sense for item #1 and was kinda what I was thinking. But it does lead one to believe you can't live migrate anything with a single host even if you have shared/remote storage available unless you poke around and experiment with different buttons like i did.
@Danp Thanks for pointing me in the right direction. I was following an older howto where --global was not specified. That was my first problem - now fixed!
Second problem was that I had installed into the root directory of Centos7 so the paths for creating the links were different. Once I had found the correct paths and created the links all was good.
Thanks again.
Frank.
@fx991 the SR scans can and have been helpful in detecting storage issues for me. Sometimes when my ISO library goes offline but XCP-ng has not detected the failure and still shows it as connected I usually notice it from the long running SR scans that get stuck.
The "Connection to VM console..." task is when you have a console window open to a VM or Host...hence the reason why you can't cancel/end it...if you want to get rid of it then close all open console windows
I already opened one: https://github.com/vatesfr/xen-orchestra/issues/4882.
pdonias created this issue in vatesfr/xen-orchestra
closed
[VM] Network: show IP addresses in front of their VIFs
#4882
I can already confirm that I could trigger 2 Jobs manually in XO and it run successfully.
Thanks!
The scheduled ones I will see tomorrow and report if it would fail, but it is not expected.
It could, I don't know what XCP-ng Center can do in details. But again, this is NOT a problem.
I said it 3 times, why do you think it's still related to your coalesce problems?
It's the default parameter of your template. XCP-ng Center is probably forcing fixed memory, XO is just doing template recommendation.
You can change values at creation in "Advanced" section.
@Danp As soon as I read that, I thought "I think I've been down this road before." Sure enough. I gave it 2G of RAM and it wouldn't build. I gave it 4G of RAM and I watched using systat and that final step went to about 52% of RAM usage. It has completed. I routinely run Xen Orchestra on a 1G VM because it's rarely used and it runs fine that way. But building it clearly takes a lot more RAM. I'll update my internal notes. It might be worth it to update the building from source docs to mention having enough RAM.
Thanks for hitting the nail on the head with that advice!
XOA got its own numbering, unrelated to xo-server or xo-web: it'a all a matter of a coherent "whole", including dependencies etc. Thing we can't provide when built on sources.
Please test and report You can switch to latest too, doesn't matter.
@luiscamaral Let me reply to myself. If you update xoa it will show user and password as in bellow description:
Template for Alpine Linux 3.10, with 'root' username and 'xohub' password, DHCP enabled
