Posts made by rtjdamen

@flakpyro we are still on 8.2 sor maybe there is some difference there.

@flakpyro are u running the latest xcp-ng version 8.2 or 8.3?

@flakpyro i have just tested live migration and offline on our end, both kept the cbt alive. Tested on both iscsi and nfs.

@flakpyro is there any difference in migrating with the vm powered on or powered off?

@flakpyro both scenarios

@flakpyro i can't reproduce this on our end, after migration within pool on the same storage pool the cbt is preserved. When i migrate to a different storage pool the cbt is reset.

@florent sounds like a plan! i will keep an eye on them and let u know the results!

@flakpyro no on my end there is no difference for nfs or iscsi on XOA backups, we only had this issue with Alike Backup, my assumption was this would be the case in XOA as well, but not at this time.

What i found out is that one of my vms facing this issue has 2 disks, both on a different SR, i am moving one of the disks to the same SR and check tomorrow (tonight will be a full after migrating) if this is still the case there.

The other vm we face this issue on is has both disks on the same SR so that cannot be the case there. keep u posted on the results.

@florent thanks for letting me know, on our end this error seems to occur on the same vms every time, it are just a handfull. Could it be these vms are facing higher load on them what causes xapi tasks to take longer then expected?

@chr1st0ph9 i understand a fix is being made for this, @florent patched our proxy yesterday and since then no more fulls so far!

@CodeMercenary i have seen this as well, one of our backup repos was almost out of space, this decreased the backup speed, we thought of issues on the xoa side but it was just related to the repo itself…. So it is good to check both. The 1 gig part makes sense.

@CodeMercenary haha, i know what u mean, restarting things is allways giving other issues, i am happy a workaround is available to get the nbd connections to be released. I asked vates if this is something that could be implemented in XOA in the future, that would make everybody's live a lot more easy!

@CodeMercenary we have seen this multiple times before, if there is an issue with the backup job or a backup fails unexpected the NBD connection for that host is not closed correctly and it holds the snapshot. The only way so far is by rebooting the host to release this lock. However i understand from vates support that if this is the case there is a workaround available to release this vdi by carefully killing the specific xapi-nbd process on that host. I don't know how this works and i think this is not something that u should do yourself but maybe support can assist you with this.

@flakpyro i think that would be a good test, can u check how it is behaving on iscsi on your end?

@flakpyro in general this error means that the cbt is not valid, we have seen this as well and i know vates is looking into this. In general we saw this problem more on nfs then on iscsi, not shure if it is nfs related but maybe if u have access to an iscsi target try your results there.

@andyh no cbt should be disabled, u can’t migrate an cbt enabled vdi.

You need to remove all snapshots before migration and disable cbt. Storage migration is not supported when cbt is invalid. I believe xoa should do this automatically however.

@StormMaster i understand, we are also not using this on these vms but it does make sense, something is breaking the cbt chain and causing a full, question is if this is caused by the backup job or something else. Thanks for your input.

@StormMaster thanks, seems logical if u backup the same vm with 2 different solutions, but in our case we don't use a different backup tool to do so. We do use Alike for some smaller backups but not this specific vms.

Since the latest release we see a lot more fall back to base errors, anyone else having the same issue?