Offline
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
@RobWhalley saved the day
We are still working on it to better understand why it fixes and improve the situation
you can uncheck the "Merge backups synchronously" in the advanced view of the backup job to have it run inside the backup job, thus making it visible
(we are reworking the internal design for better observability, but there is a lot of job before)
@dnordmann the tunnel is closed. By the way the patch will be release tomorrow on latest, by the end of december on stable
thank you all for your patience and your help identifying the root cause of this bug
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
@dnordmann said in V2V - Stops at 99%:
Ticket#7747444
and I just opened another ticket for the other client that is having the same issue. Ticket#7748053.
Support tunnels should be open for both clients.
Thanks!
I deployed the patch on the new client, if it's ok I will do the second one after
@dnordmann if I remember well you have opened a ticket on your xoa , can provide us the ticket number and we can patch your xoa ?
if you are using xo from source, you need to change branch and then restart xo-server
@MajorP93 that's nice to hear taht it, at least solved the issue
are you using a xoa ? or a compiled fro source ?
what is the user that run the xo service ?
@dnordmann @tsukraw
thank you for your patience, we found something while working with the xcp storage team, and there is an issue with the last block size
Can you confirm that the failing VM has at least one disk with a disk with a size not aligned with 2MB ?
Could you test this PR on the failing import ? https://github.com/vatesfr/xen-orchestra/pull/9233
regards
@tsukraw hard to answer as is
do you have anything in your xo log ( console / journalctl ) or in the task log ?
If not, the log of xo should say something about " nbdkit logs of ${diskPath} are in /tmp/xo-serverxxxx"
can you check if there is something at the end ?
1.5TB is ok in vhd
@tsukraw we will have to improve the doc
First migration :
[vm source] => [vm on xcp]
Check
[vm source] => [vm on xcp] => [copy/clone of vm on xcp]
test on [copy/clone of vm on xcp] <--
remove [copy/clone of vm on xcp]
Final migration
stop [vm source]
launch the same migraiton. The data already transfered won't be retransfered
applues the fixes you had to do during previous test
start [vm on xcp]
@tsukraw yes it is already possible , and there is even a documentation : https://docs.xen-orchestra.com/v2v-migration-guide#-final-migration
works the same through xo-cli ,or through the UI. You'll need to keep the same storage/template for both migraiton, don't create new snapshot on the vmware side, and it can only works if warm migration works
