You were using qcow2 instead of VHD, right?

@joeymorin said in Every VM in a CR backup job creates an "Unhealthy VDI":

How can an issue with coalescing a VDI on local SR A1 cause that?

It can't. Coalesce issues are local to their SR. But you must fix those anyway, because this will cause big troubles over time.

How can a VM's VDI on pool Y, host C, local SR C1, replicated to pool X, host B, local SR B2, be affected by a coalesce issue on with a VDI on pool X, host A, local SR A1?

It can't.

But it depends on what you mean by "affecting". Coalesce is a normal process as soon your remove a snapshot. Snapshot removal is done both on source and destination during a CR.

CR isn't a different operation than doing a regular snapshot, there's nothing special about it.

So why it fails on your specific case? I would first make things clean in the first place, remove corrupted VHD, check all chains are clear everywhere and start a CR job again. I bet on a environment issue, causing a specific bug, but there's no many factors that's it's really hard to answer.

I'm not sure to get everything but I can answer the question: not on a different pool, but coalesce for the whole pool with a shared SR yes (a broken VHD will break coalesce on the entire SR it resides on, not on the others).

CR shouldn't leave any persistent coalesce. Yes, as soon a snap is deleted, it will need to coalesce, but then, after a while, coalesce should be finished, except if your CR fast enough to have almost not long before you have another coalesce and so on.

Hi,

Question for @florent

The issue is unrelated to XO, but a storage issue with corrupted VHD. As long it's here and not removed, nothing will coalesce.

UUID collisions are very very very unlikely, even at scale.

Can you grep on the word exception? (with -i to make sure you get them all)

You have to check your host SMlog to see if you have a coalesce issue

I'm not sure who to ping exactly Maybe @Team-XAPI-Network with some experience on the cert issue?

We made some fixes very recently (yesterday), can you check you are on latest commit? (if XO sources)

Hi,

Question for @yann

Then I can't tell if there's any modification made, so I would ask to:

• Try with XOA (even XOA Free allows adding host to a pool)
• Make a clean source install from scratch following our doc https://docs.xen-orchestra.com/installation#from-the-sources

Alternatively/in parallel, you can open a ticket in the Jarli01 Github repo to report the issue.

Hi,

How did you install your XO in the first place?

Thanks everyone for the precise feedback, it was really helpful! And thanks @florent for the fix

Adding @Team-OS-Platform-Release in case that rings a bell

That's unrelated. This might need a deeper investigation, I'm not sure to get why nothing is displayed while you have a working IPMI plugin…

Can you check your browser console to see if there's a issue in there?

@probain said in Snapshots are no longer being pruned? Commit 58f02:

05c6f87a1212e81c51e63f6a585b9e97a3c1bfb2

This commit is https://github.com/vatesfr/xen-orchestra/commit/05c6f87a1212e81c51e63f6a585b9e97a3c1bfb2

It's related to retention, so that would explain the issue if there's a bug in there.

0 fbeauchamp committed to vatesfr/xen-orchestra

fix(backups): long term retention taking the most recent values (#9180)

That's a very good feedback, I will tell the team internally. Pinging also @florent and @Bastien-Nollet in the mean time.

Hello,

Thanks for the report, that's weird. Pinging @Bastien-Nollet or @florent in case it rings a bell.