@taghjichte Try importing the OVA files using XOA (Import > VM).

@olivierlambert Yes, the tool is called xapi-explore-sr. Installation and usage details can be found at https://github.com/vatesfr/xen-orchestra/tree/master/packages/xapi-explore-sr.

@Tristis-Oris Did you install the patch on all of the hosts in the pool? Have you tried rescanning an SR to kick off the GC process?

@Tristis-Oris Not AFAIK but it wouldn't hurt to be sure that the latest fixes are running.

@Tristis-Oris There's a fix for the time out during leaf coalesce on XCP-ng 8.3 that should be released soon. You can install it now with the following command --

yum install https://updates.xcp-ng.org/8/8.3/testing/x86_64/Packages/sm-3.2.3-1.15.xcpng8.3.x86_64.rpm https://updates.xcp-ng.org/8/8.3/testing/x86_64/Packages/sm-fairlock-3.2.3-1.15.xcpng8.3.x86_64.rpm

@Tristis-Oris said in SR Garbage Collection running permanently:

something like this?

Yes. Are you running XCP-ng 8.2.1 or 8.3?

On the snapshot issue, do you have any idea how they are being created?

Hi Tristis,

On the GC issue, have you checked the SR's Advanced tab to see if it lists VDI to be coalesced? You may also want to check SMlog to see if there are exceptions preventing the GC from completing.

For the image, check your backup jobs for the following settings --

This behavior should be present on all SRs where these options are enabled on the associated backups.

Regards, Dan

@cgasser This sounds like a perfect candidate for the new Backup Sequence feature. See https://xen-orchestra.com/blog/xen-orchestra-5-99/ for full details.

Unsure why this detail wasn't included here, but his support ticket indicates that HA is enabled on the pool.

Could also be due to this -- https://github.com/xapi-project/xen-api/issues/4323

olivierlambert created this issue in xapi-project/xen-api

open Mysterious failure in HA with HOST_NOT_ENOUGH_FREE_MEMORY #4323

@bigdweeb said in Migration fails: VDI_COPY_FAILED(End_of_file):

"message": "VDI_COPY_FAILED(End_of_file)",

This is the only thing that that I saw as problematic. If you have backups, then that is your best option to recover this VM. If you don't have backups, then the data must not be that important, right? J/K

You could try copying the data from inside the VM using dd to transfer the data between VDI.

@bigdweeb My guess is that the VDI chain contains some corruption. You may want to check SMlog to see if it contains additional details. You could also use vhd-util to check for corruption.

@taghashseven Have you checked the documentation? https://docs.xcp-ng.org/management/manage-at-scale/xo-api/

@ewoudstra I assume that you are using a service to start XO. Did you restart the service after performing the update?

@ewoudstra Are you on the master branch? What is the output from git rev-parse --abbrev-ref HEAD?

If you are using any local storage SRs on this host, then be sure to migrate them to other storage before you remove the host from the pool.

@spcmediaco Check the VM's Advanced tab in XO and make sure these options are not enabled --

@df-cgdm You are correct. That feature isn't currently available via the REST APIs as previously mentioned by Julien earlier in this thread.

@McHenry Did you try with pool-param-set?

xe pool-param-set name-label="New Pool" uuid=pool_uuid

@ph7 This is being investigated by the XOA team. We will update this thread when more information is available.