@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.

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

@RobWhalley saved the day
We are still working on it to better understand why it fixes and improve the situation

@RobWhalley nice work, I am testing it right now

@olivierlambert Nice catch
CBT will only be enabled when using purge data , I will fix the first one

(this is because CBT does not improve things without purge snaphot data , but has some edge case , so at least we won't enable it for nothing )

@olivierlambert @Gheppy that is a nice catch and it gives us a interesting clue

I am currently working on it

@manilx this is merged

@manilx said in Our future backup code: test it!:

@florent Yes, just fine.

ok, so that's an issue with the mirror. I reproduced this night on my lab
I am working on a fix

@cairoti you should be able to add it as a remote ( not as a storage repository on xcp-ng)

@cairoti you know you can backup directly to S3, it will be more efficient that way ( we rework S3 code 3 years ago , because of limitation of S3)

andrew is right
(nice storage size)

you should type a 32 char hexadecimal key ( 0 to 9 A to F )

Note that if you lose this key, all your backup will be lost, and this can only be changed when the remote is empty

@robyt your doiing incremental backup with 2 step : complete backup ( full/key disks) and delta (differencing/incremental) Both of theses are transfered through an incremental mirror

on the other hand if you do Backup , it build one xva file per VM containing all the VM data at each backup. These are transfered through a Full backup mirror

we are working on clarifying the vocabulary

@afk said in What is the status/roadmap of V2V (Migrating from VMware to XCPng/XO) ?:

Great news ! Thanks @olivierlambert and @florent and let me know if you need some information on the vmware side.

yes we are prototyping with vddk , it should open some interesting possibilities. stay tuned, hopefully by the end of the summer (I am saying it again : for a prototype)

as a shameless plug, we are looking for users with VSAN to ensure we don't break thing for it

@CodeMercenary Looking for in detail would need a support tunnel
it's probably a vdi that has been deeemed incorrect by the cleanup script. The easiest way to fix it in mirror backup is to delete the most recent backups of this VM on the target , they will be re transferred from the source.

If your retention is the same, you can even ourge all the backups of this VM on the target and restart the mirror backup

the mix shouldn't be an issue in itself

@robyt are you using full backus ( called "backup" ) on the source ?
because incremental mirror will transfer all the backups generated by a "delta backup" whereas it's the first transfer or the following delta

(our terminology can be confusing for now)

is there a reverse proxy before the xoa ?

@DevFlint the https://XOA_URL/rest/v0/tasks endpoint exists, but it's not yet documented through swagger

you should be able to add ?sync=true to the url to get the immediate result, but it can fail with a timeout if the creation takes too much time ( for example : migrating a big template )