@Pilow We pushed a lot of memory fixes to master, would it be possible to test it ?

@henri9813 the warm mode is more manual by XO, and it can replicate from almost any version to any version, or any CPU to any CPU
the direct migration has some precondition : always migrate to te same or superior version. Live migration also add some condition on the CPU brand and generation

@dave.opc that's it

keep us updated on this

@acebmxer yes after the first migration, XO knwo that the migration is incomplete and that you may want to finish it later. But if you start this VM direvtly , it will write some data, thus it won't be in sync anymore with the Vmware snapshot. Then XO won't be able to resume

You can start a copy of the VM ( XO will handle it for you ) and delete the copy when you're done

My advice is to migrate this VM to the right SR and then do the resume. But keep in mind that the V2V tool is intended to target only one SR, so migrate all they disk to the same SR, and select the right one when resuming the V2V. You can change the network after

@dave.opc it should work . Add [NoBak] to one disk, transfer it, then remove the [NoBak] on the 2nd , restart the transfer => the first one will only transfer a delta , while the second disk will be transfered as full . If you put [NBak] on the first one for the second transfer, it will be handled as a disk deleted and will remove it on the replica

Note you will have the same issue if ( when ) you'll need to do a full backup later on, for example if there are any replication issue, or if you want to ensure your base copy is not corrupted later on

hi @planedrop
could you send us the full json of the backup log ? is the disk still attached to dom0 ( in dashboard => health )
(the task will disappear after 24 hours at worste)

@john.c yes for sure, and maybe we will be able to set the chunk size on a future date ( especially since we did some of the ground work for vhd / qcow2)

@rizaemet-0
sure : "@aws-sdk/client-s3": "^3.54.0",

@Andrew and the CR is completing correctly ?

@Andrew is it always the same VM/disk ?

@olivluca skip ssl check in the import form

@olivluca even with the self signed toggled on ?

@olivluca it looks like a network issue , can XO access the vsphere/esxi through NBD ?

@blueh2o the restore should have timeout . Is it possible that it run more than 24h ?
you should restart xo-server, increase the timeout and retry https://docs.xcp-ng.org/management/manage-locally/api/#_24h-task-timeout

@guillemrebull in your xo logs, you should have a line like nbdkit logs of ${diskPath} are in ${tmpDir}

could you copy here the file in tmpDir ( something like /tmp/xo-serverYYYY/stderr ) ?

@MajorP93 ineresting
so the same file set to restore was locking the xoa in tar but not in tar gz

do you know how many files and their size in this folder ?

@jsajous26 AFAIK this is not possible to call a script inside the VM through the guest tools. Maybe on veeam side there are other way to do this ( throug ssh / powershell) ?

@nikade any logs can help fix the issue, but don't make too much effort on getting them back. We will meet the issue again one day if we do not have fixed it
(importing data is fairly honest : any missing bits and the xapi, the file system or both explodes immediatly)

@jsajous26 sorry I misread. I don't know how ti setup this while using veeam

@jsajous26 we have something for this, web hooks : https://xen-orchestra.com/blog/xen-orchestra-5-75/
doc : https://github.com/vatesfr/xen-orchestra/blob/master/%40xen-orchestra/xapi/docs/vm-sync-hook.md?ref=xen-orchestra.com