@Pilow said: @ph7 try to put RETENTION to 1 in the schedule, as you are using LTR parameters I was running the shedule with 20 mins backup retention and it is running fine together with the LTR And here is the manual I ran at 14:56 removed [image: 1775140196713-screenshot-2026-04-02-at-16-28-13-backup.png]

@Bastien-Nollet I'm running c1e5f btw

@joeymorin said: I observed similar behaviour. Two pools. Pool A composed of two hosts. Pool B is single-host. B runs a VM with XO from source. Two VMs on host A1 (on local SR), one VM on host B1 A2 (on local SR). Host A2 has a second local SR (separate physical disc) used as the target for a CR job. CR job would back up all four VMs to the second local SR on host A2. The behaviour observed was that, although the VM on B would be backed up (as expected) as a single VM with multiple snapshots (up to the 'replication retention'), the three other VMs on the same pool as the target SR would see a new full VM created for each run of the CR job. That rather quickly filled up the target SR. I noticed the situation was corrected by a commit on or about the same date reported by @ph7. Incidentally, whatever broke this, and subsequently corrected it, appears to have corrected another issue I reported here. I never got a satisfactory answer regarding that question. Questions were raised about the stability of my test environment, even though I could easily reproduce it with a completely fresh install. Thanks for the work! edit: Correction B1 A2 sometimes it's hard to find a n complete explanation without connecting to the hosts and xo, and going through a lot of logs , which is out of the scope of community support I am glad the continuous improvement of the code base fixed the issue . We will release today a new patch, because migrating from 6.2.2 to 6.3 for a full replication ( source user that updated to the intermediate version are not affected )

@ph7 that's fine, keep on testing our new XO-6, we are very happy with all our community feedback

Since I'm not used to using git, I was running a few tests on my "test" host. I had made a change in my "one line commando" My memory is not in best shape so I forgot the change and ran it in my update. Now It's sorted out and ran a new update and voila

@lsouai-vates

@olivierlambert can you close this thread?

@lsouai-vates Today I noticed that there is the same in xo5 (commit 25192) Jobs with disabled jobs but scheduled in a sequence job are shown with Not backed up VMs [image: 1747997034588-9d25866e-a8b8-4bd6-85ac-bcb5973fd6fc-image.png] By the BCK_Running tag, it is backed up [image: 1747997147334-f5471bb0-7600-4d6e-ad81-da9c13dfa6bd-image.png]

Note: just do a yarn && yarn build and it will work. The XO 6 build might be broken, but that's not surprising, it could happens.

@ph7 I ask the XO team about it, thanks for the report.

I increased the dom0 RAM from default 1.75 to 2 GiB Hopefully this will do.

@ph7 Thanks for the report, we'll check that

@Danp Thank you very much! Missed it

@Danp Yes of course You are correct I moved it to local storage a few weeks ago My bad

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.

@pdonias said in Wrong colours in dashboard: Thanks for the feedback, we'll take care of that. To get more of an idea about the HDR technology checkout these links:- https://www.viewsonic.com/library/photography/what-is-hdr-hdr-vs-sdr/ https://en.wikipedia.org/wiki/High_dynamic_range https://www.dolby.com/technologies/dolby-vision/ Some of the links refer to videos though the graphics technology applies outside of videos, these will help you get an idea of how the technology will affect the user interface of XOA and XO Lite. In this case it's the colours part of HDR which is relevant as the user interface, doesn't have photos or videos in it but does still have other forms of imagery. Though the client devices may be used with other usage which the full HDR is appropriate for, so thus have compatible hardware and have the feature active. @ph7 If your interested in finding out more about HDR you can also check out the links above. I also added my input about your issue, as I knew that HDR can play a part in the reproduction of colour etc in an image, or user interface. So can have an impact on what colours are used on the dashboard, as well as other parts of the user interface.

@ph7 Some of the errors you encountered are intended. We don't allow values in the "Virtual Machines" field if "Exclude VMs" is disabled and "All running VMs" is enabled, because it would make the plugin configuration confusing. However you're right, there seems to be an issue when the VMs are selected and then removed. The value becomes an empty list instead of being undefined, which causes the validation to fail when we try to turn off the "Exclude VMs" option. I'm going to create a task on our side so that we can plan to resolve this problem. In the meantime you can work around the problem by deleting the monitor and recreating a new one with the same parameters.