Offline
On tomorrow 's release we will:
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
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:
@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
@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
@ItzJay said in Problems import vm Vmware to Xcp-ng from import Vmware and OVA:
@florent By base OS you mean the based Debian XOA appliance?
yes , I was not sure it was a XOA. If it's a xoa, how old is it ? would it be ok to open a ticket so we can check it on monday ?
@olivluca what are your base os ? because on a XOA, I thik gnutls ins installed, so nbdkit is compiled with tls supports
@flakpyro the double close will be improved but this is only a log issue (we close the file twice to ensure it is closed in the nominal case and in case of error )
we did the minimal patch to ensure the root issue is addressed before weekend
@flakpyro we did found a race condition in our code
We will do a complete post mortem after , but for now :
@Pilow we really did only add one small log . we'll need to dive deeper for a real cause ( and fix)
Let me create a card do check this hypothesis ( and do a the fix @andrew )
@andrewperry hi this is an identified issue on xapi / storage side
this commit is making it visible .
Pinging @anthoineb here for more info
@Pa3docypris the other snapshots are correctly deleted ?
are these VM on a specific storage ?
Do you have anythin in the xo-server logs ( like in journalctl ) VDI_IN_USE ?
can you post the full job JSON ( on the top of the backup log there is a download button ) ? eventually by direct chat to me if you prefer to keep it private
On tomorrow 's release we will:
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
