On tomorrow 's release we will:

• reduce the polling for the patches list
• add more debug to know exactly what request go through the xo6 api (rest api)

following this we will add core xo metrics to the openmetrics ( prometheus) export to allow users and support to dig through real world data when needed

@Forza

Cancelling a backup run is also on our roadmap ,as soon as we have done reworking the tasks to use xo-task on the full chain, and not an hybrid of various iteration of the tasks objects

better tracking of the backup run is also on our roadmap , this is also linked to the task changes plus are some issues with the size on the remote before being able to do this

In any case, both are on our backlog

@Pilow said in Veeam backup with XCP NG:

@olivierlambert I get you.

Same in veeam and synthetic fulls, it's only between the server/proxy and the repository.
but we get a progressing percentage while the job sits while doing the synthetic full.

would be cool to "see" the progress of merging.
why ? bad habits from previous technologies used I guess.

Giving better observability is something we are working actively on , this is tightly coupled with being able to stop a task, and I hope we will be able to show the progress soon

@manilx yes, that's it

we should change the "full backup interval" to "base/complete backup interval", to clarify what is a full . And we will do it.

we are reworking the import code , along the new backup code ( https://xcp-ng.org/forum/topic/10664/our-future-backup-code-test-it ) to unify the differetn disk transformation path

For now:

• V2V handles flat, cowd, sesparse, stream optimized vmdk in the format "metadata.vmdk and a data file ) and ova ( for VSAN)
• disk import support monolithic vmdk ( cowd, sesparse, streamoptimized )
• ova improt support only stream ova with streamoptimzed vmdk inside

@andrewreid Yes, I can't wait to share it with everybody.

@AlexD2006 thanks for signaling this, we just merged a fix, that fix it on our labs
can you test it on your side ?
https://github.com/vatesfr/xen-orchestra/pull/9202

fbeauchamp opened this pull request in vatesfr/xen-orchestra

closed fix(backups): getOldEntries must accept entries without id or timestamp #9202

@AlexD2006 this looks like the right issue, we will look into it immediately ( yesterday was a public holiday in France)

@Andrew then again, with such a precise report, the fix is easier

the fix should join master soon

found it , there was not one, but 2 bugs
albeit small they were putting the xo backup in a incorrect state
the fix is here, and will be merged as soon as possible and then released as a patch for xoa users
https://github.com/vatesfr/xen-orchestra/pull/8780

really thank you everyone for the information

fbeauchamp opened this pull request in vatesfr/xen-orchestra

closed fix(xapi): respect the config file setting for preferNbd #8780

@kratos no, it's not that rare. I even saw in the wild replication on the same storage (wouldn't recommend it , though )

the cross pool replication is a little harder since the objects are each split on their own xen api, so the calls must be routed to the right one
We tested the harder part, not the mono xapi case

@kratos you probably heard the sound of my head hitting my desk when I found the cause
the fix is in review, you will be able to use it in a few hours

@kratos @pilow is it possible that your replications are in the same pool ?

@Pilow

we had as many "VMs with a timestamp in the name" as number of REPLICAs, and multiple snapshot on source VM
now we have "one Replica VM with multiple snapshots" ? Veeam-replica-style...

we didn't look at veeam , but it's reassuring to see that we converge toward the solutions used elsewhere

it shouldn't change anything on the source
I am currently doing more test to see if we missed something

edit: as an additional beenfits it should use less space on target it you have a retention > 1 since we will only have one active disk

@Dezerd and you can either add the replication to the same backup job if you have a good connection between host, or create separate replication jobs

a replication is quite neat, especially for a fast restart, since the replicated VM is ready to start

@Pilow the timestamp is on the snapshot, but you're right, we can add a note on the VM with the last replications informations

note that the older VMs replicated will be purged when we are sure they don't have any usefull data , so you will have only one VM replicated , wuth multiple snapshots

@ph7 yes this is expected even if we did not have time to communicate on this yet : https://github.com/vatesfr/xen-orchestra/pull/9524

the goal is to have more symmetry between the source ( on VM with snapshots ) and the replica ( on VM with snapshots) . The end goal is to use this to be able to reverse a PRD , and to allow advanced scenarii like VM on edge site => replica on center site => backup on central servers

but it should not do full backups, it should respect the delta / full chain

fbeauchamp opened this pull request in vatesfr/xen-orchestra

closed feat(backups): symetrical backups #9524

@MajorP93 we merged a lot of changes yesterday , so it's on master

it clean more aggressively the task log, and more cleanup after backup; We are still looking for other possibilities , but for now it's our best bets

patch done by @bastien-nollet

@ElFritto can you do a yarn && yarn build at the root of xen-orchestra ?

edit : found it, we will do a patch