@andrewreid Yes, I can't wait to share it with everybody.

@ronivay that's a great information. I can reproduce the comportment with xenserver 7.1 CU 2
Thank you

@Andrew I am reproducing the problem : if the VM has mulitple disks, the import only handle the first one and freeze

@stormi at least it failed on 7.1CU2 installed this morning.
I implemented a fallback not checking the version, but catching the specific error message and going back to the old method

@Andrew yes , thank you
@JVComputers thank you for helping us fix it

@s-pam I answered on the ticket and deployed the fix.

@andrewreid hi andrew, I think it's good to discuss of it here.

We added a lot of information in the clean phase to ensure we do not miss the information causing full vhd backups when delta may have seem ok

1. means a merge have been interrupted and could not be restarted safely
2. an alias ( a link ) to a vhd is missing

theses errors points to a ( or some ) interrupted backup and XO detecting it and recover : removing the broken files and probably making full backup after

3. is interesting since its' in the aws sdk, I will try to find where does it come from. Also you reproduced it from master. Do you use a specific configuration of your bucket ( like object locking ) ?

@olivierlambert I am not sure it would be trivial to restart a delta vm backup : since the job did not really terminate, we did not go through the clean vm phase at the end

• restarting the job may lead to broken vhd used as if they're fine.
• a dephasing between snapshot and backup will lead to more full backups than needed and more pressure on the backup
• restarting the full vm backup when only a vdi failed ( or part of a vdi) seems suboptimal

I would better harden each backup phase and retrying them individually if needed than trying to restart the whole VM.

@gsrfan01 can you give us more detail of the phase that fails ? clean / snapshot/transfer/merge ?

@Andrew even this one disk ,there is some padding that freeze the import process

can you try the branch of this PR : https://github.com/vatesfr/xen-orchestra/pull/6284 ?

fbeauchamp created this issue in vatesfr/xen-orchestra

closed fix(ova import): drain disk entry completly #6284

@Andrew I am reproducing the problem : if the VM has mulitple disks, the import only handle the first one and freeze

@chelle_belle If you can open a support tunnel I can deploy the fix today ( with a more reasonable compression level of 1 , thanks @Andrew )

Can you open a support ticket with the tunnel information ?

@chelle_belle can you test this branch : fix_ova_speed

there will still have a pause after the 5kb and after each disk, but it should speed up things . I will look for other performance optimization during this sprint.

@chelle_belle so the ova is a tar containing many files, (one 4KB ovf file containing the metadata and one vmdk file per disk containing the data)

since it's a tar we need to know the size of each file to be able to stream it

but the most supported subformat of vmdk is the stream optimized , which mandates to compress each 64KB part of the disk. Since we can't compute the compressed size of the vhd transformed to vmdk we need to transfert the disk, compress it to vmdk , keep track of the compressed size, then start again, this time sending the data

Since we can't store the vmdk on xo-server disks, we need to transfer and transform the disk to vmdk twice. And the transform process is quite slow.

As I write this, I am wondering if I can create a less efficient vmdk with empty spaces at the end so that I can do it in one pass.

I will test it and let you know the result

Hi @Andrew the backup listed in restore (and health check) should be complete. We create an alias to the real vhd directory and this alias is created only after the transfer is finished.

We are reworking the logs to be more precise and visible in the UI, because some of these are not needed anymore (and some are really hard to understand (like the unused message that can be reached by two code paths)

maybe it's more a restore heath check issue. Do you have more details?

@ronivay hi, can you test this branch fix_console_bis before we merge it?

thank you for your report

@ronivay hi , something should not have worked as intended, I'm working on it. Your server is a 7.6 ?