I also have this problem in my XO-CE (ronivay-script) at home
I get the mail report after 4 days
A reboot resets the memory
the XO-CE have 3.1 GB and the Control domain memory have 2 GB
Node v24.13.1
Running Continuous Replication and Delta Backups
@acebmxer said in VM Pool To Pool Migration over VPN:
Maybe VPN overhead.
Have You checked the VPN capacity spec of Your firewalls?
No idea if anyone have "fixed" anything
No, the XO commit 5fcb6 hang for ~3 min at reboot today.
edit: I disabled the sceduled reboot yesterday.
@DwightHat
No
I did schedule a reboot of XO every morning and it seems it has worked because I "forgot" about it
No idea if anyone have "fixed" anything
I'm not running https and still on node v22
@Gheppy
My links from 6 to 5 works fine
Haven’t tested all of them of course, but quit a few and none of them have faild
I run these kinds of backup jobs
In ContRep, Conf/meta and in one of the Full Backup jobs I get Report when Never
But they are enabled in XO5 with mail address and Report when Skipped and failure
I fired up my 2nd XO wich is a ronivay script version.
Ran the update to latest commit 9f387
When I logged in, It start in the XO5 page
In my 1st XO "from docs", It start in the XO6
Maybe ronivay is not up to date with the new #release" of XO6
If You are running this type script, maybe that is the culprit
@probain Well I’ve been running commit 035ee for a few days now and haven't had any problems. But haven't done a lot of work with it.
When I update, I always run some kind of full/complicated update since I've had some problems before and with this type of update I've never had any issues.
sudo su
nvm install 22 && npm install --global yarn && cd ~/xen-orchestra/ && git checkout . && git pull --ff-only && yarn && yarn build --force && yarn run turbo run build --filter @xen-orchestra/web && systemctl restart xo-server.service && cd && systemctl daemon-reload
Or maybe just a simple CTRL F5 in Your browser will work 
Commit 035ee in dashboard
I'm not sure if it's a good idea to show a Backup issue every time a Cont.rep. job is run
It would be more or less a static feature for somebody who run Cont rep frequently. and as a consequence won't react when a proper alert should be displayed
Are you in UTC+1? This one might simply be because the VM's name shows the UTC time while, in the tables, we convert dates to your actual timezone.
Yes, I'm in CET, UTC+1 and 24h
Yes the Cont.Rep. VMs show UTC. During summertime, it was 2h off.
Its just cosmetics, not "urgent", but still in AM/PM
These are also still in AM/PM
@acebmxer
If I remember correctly, if You migrate the VDI to another SR , it will be shrinked.
But I don't know for shure
@acebmxer
I think that the disk file don't shrink automatically.
You probably had something in there that has been deleted
said in 
️ XO 6: dedicated thread for all your feedback!:
#Disk Space
46 (73) GB
I saw now that it's implemented under the VM tab, but it would nice to also have it under 
but it still works on 76abf from dec 09
Crap
File restore doesn't work on free version, sorry
@Pilow
I'l spin up my XOA's and test
granular file restore
I'm not sure what granular file restore means but when I read Your first post, I had to test backup/file-restore and I was able to restore files.
XO CE 1640a of dec 03 if I remember correctly
In thin provisioning It would be nice to have info about a VMs actual use of disk space
#Disk Space
46 (73) GB
@pdonias said in ️ XO 6: dedicated thread for all your feedback!:
@ph7 If we answered your other messages, most likely we have it in our backlog. But just to make sure we're not missing anything, you can indeed put the links here and we'll check them. Thanks again!
I found another link that isn't completely fixed
https://xcp-ng.org/forum/topic/10613/suspicius-presentation-of-time-in-backup/
It's not only concerning XO6 but also XO5 and XCP-ng