Yes but if you connect via another XO, I think you don't have the right namelabel (IIRC)

There's something fishy somewhere, the hard thing is to pinpoint exactly what. If you upload with one XO, we'll save (in XO) the name label of the VDI (so you see the name, it's not the filename per se because XO doesn't have access to the storage, only XAPI does).

How does XAPI name the .img file in the first place? IIRC, when we upload via XO, we set the name label but we have 0 control on the file naming on the ISO SR itself.

I think we discussed it internally, IIRC it's not XO doing any renaming, but the toolstack. Adding @andriy.sultanov or @psafont in the loop

Question for @Team-Hypervisor-Kernel maybe or anyone with guest console knowledge

Ping @pdonias do we have a rule to check the avoid using the "replicated tag"?

Hi,

I was about to suggest to use backup health check but it seems you'd like to avoid it In this case, I don't really have an answer, maybe @Bastien-Nollet or @florent does.

Ping @Team-Documentation-Knowledge-Management

Hi,

IIRC, it's a known (cosmetic) problem (just the report, but the tools are still working). Also IIRC, @dinhngtu has or works on a patch.

Hi,

In theory, it should start just after the snap, not waiting to boot. Let me ping @Bastien-Nollet or @florent

I think it's planned for XO 6 adding @gregoire in the loop

I will leave the @Team-Storage to answer that

On the bottom of each documentation page, there's an "Edit this page" link you can use to contribute

Hi,

You can provide the ticket number in here so I can ping relevant people. Note that we priorise tickets while trying to keep our SLAs

Perfect, can you link it here? This way I could keep an eye myself

Wait and see!

Hi,

If I understand correctly, it is related to VEEAM itself, right? If it's the case, you might have a faster answer on VEEAM forums (also it would be great to submit them those kind of bugs so they can potentially fix it). Maybe there's someone around here having the same experience, we'll see

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