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

@acebmxer the connectnbdclient error won't be in the task log, but in the system log

qcow2 backup need NBD

@acebmxer said:

connectNbdClientIfPossible

yes connectNbdClientIfPossible is the nearest error message from the real cause
Now, why does it fails ?

nbd should be enabled on the network used for backups , do you have a default backup network defined ?

xo must have at least one VIF on this network

@acebmxer do you have something in the xo logs ( journalct probably ) ?

@MajorP93 said:

@florent Thanks!
I did not have time (yet) to look into the heap export due to weekend being in between.
I will update to current master and provide you with the heap export in the following days.
Best regards

no problem , the sooner we'll have these exports, the sooner we will be able to indentify what is leaking in your usage, since we already plugged the leaks we reproduced in our labs

we merge the code into master ( including the code to allow a heap memory export )

@MajorP93 I am not sure of which branch.
can you switch to https://github.com/vatesfr/xen-orchestra/pull/9725

then

when running this branch :

wait for the memory to fill
find the process running xo ( dist/cli.mjs )
send signal : kill -SIGUSR2
a file is created in `/tmp/xo-server-${process.pid}-${Date.now()}.heapsnapshot` 

Note that these exports can contain sensitive data. This will freeze you xo from a few seconds to 2 minutes, and the memory consumption after will be higher after, but this will be very usefull to identify exactly what is leaking

The file will be a few hundred MB

fbeauchamp opened this pull request in vatesfr/xen-orchestra

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

@acebmxer did you enabled NBD on the network ( in the pool view ? ) is it a network accessible by the xo ?

@acebmxer you need to enable NBD on the backup to ensure ti works with qcow2

we 'll check for the progress bar

maybe a good news ?

is completely stable since yesterday's patch

@MajorP93 I think there are multiple issue for memory . Pillow and acebmxer uses proxy , so the backup memory is handled differently

are you using XO from source or a xoa ? would you be ok to export a memory heap ?