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

that's better but it still grew during the night

(and the process did an aout of memory when I asked for a memory dump)

I reduced the memory allocated to the rest api and will continue monitoring

@ph7

let's call it a day

@acebmxer after 3 hours the consumption was slightly rising, so we also deployed the latest rest api patch which is already on master : https://github.com/vatesfr/xen-orchestra/commit/0fef765ce6b4bc96b28e6af9be3d3dba3fa7dc1e

0 MathieuRA committed to vatesfr/xen-orchestra

fix(rest-api): fix memory-leak on subscription (#9707)

@acebmxer said:

@florent

This is from when patch was applied today.

I am exactly on the same screen, but I won't jinx it and emit a hope before at least a few more hours

@Pilow said:

@florent http 401 error on the pull odd

can you retry ?

@acebmxer thanks to you we have discove a new class of candidates for the fix : the TLS session that stayed behind each connection.

the branch is here https://github.com/vatesfr/xen-orchestra/pull/9725 , as soon as we are done on a QA we will patch your xoa

fbeauchamp opened this pull request in vatesfr/xen-orchestra

open Fix(xo-server): TLSSocket memory leak — stoppable + http-server-plus incompatibility #9725

@archw can you try to restore the full VM and see if the files are here ?
what is the file system on the windows VM ? is it possible that there are special permission/protection that block the files to be listed ?

a little more tricky, but we provides to to mount the backup on a linux server with the command line tool here : https://github.com/vatesfr/xen-orchestra/tree/master/%40vates/fuse-vhd

@acebmxer yes please ping Mathieu R and me ( Florent B ) on the ticket so we can get it as fast as possible

Would it be ok to extract the memory of the xoa with this PR https://github.com/vatesfr/xen-orchestra/pull/9704 ?
it should gives us pointers

fbeauchamp opened this pull request in vatesfr/xen-orchestra

draft feat(xo-server): allow heap memory export #9704

@acebmxer do you know what you did change on the backups ?

@Mark-C this is not forgotten, but file level restore has been under priorised, so it didn't get much work

it is now quite high on our backlog , so expect good news in the next months

@flakpyro that's a good news ( but at least another user saw this)

we are currently testing the branch ensuring that at least the fix don't create other issues