Offline
@farokh the VM (from source or target) are not started automatically
After the migration, the VM from on the xcp-ng host shoud be ready to start, with snapshot corresponding to the steps of the replication
this is not automatic because, for now, we put a lot of work on the disk data transfer, but there is much to do around it to ensure the VM start exactly as intended : guest tools, advanced network or storage configuration.
@farokh do you have at least one snapshot on the source ? The data migrated while the VM is running are the data before the last snapshot
The power off is effectively a call to powerOff, is there a better alternative (that can work with or without the vmware tools installed) ?
the progress bar are visible in the task view, or on the disk tab on the VM being imported ( not yet in the form , this will probably wait for the XO6 version of this page )
@farokh If my understanding it correct : it migrated the source VM correctly , without breaking anything on esxi side, but it would be better if the V2V gives more feedback to the user ?
Also, you would like to be able to select different networks as target ?
since the first testers reduced the list of supported version we added tools to compile the right version (at least on debian 12 13 )
can you retry and tell us if it's ok ?
@olivierlambert we have a WIP for S3 to improve the listting performance . It will take a few days before having a testable 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)
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)
@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 )
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
@frank-s yes please
the more detailed the bug report is, the easier it is to fix
@Gheppy and nothing in the journalctl log ?
you're right, preferNbd default value is not the same on the front and the back, we'll fix it
Most of the backup issue are solved by either removing the snapshot, or having it fa enough so thaht the next backup will be a base one, with all the data
I am still not reproducing the nackup stuck issue after this commit https://github.com/vatesfr/xen-orchestra/commit/3c8efb4dc3e1cb3955521063047227849cfb6ed3
