Wanted to post a quick update, it's been over a week now and the backups have been 100% successful.

Figured as such, but thought it was worth at least coming back here and confirming.

@ravenet Yeah another night of successful backups so I think going back to Stable did fix the issue. 2 for 2 on that now.

@ravenet All of my errors seemed related to NBD access, so if the concurrency setting was being ignored, that might be the source of the issue I was seeing.

I'll watch my lab as well and see if the concurrency is being respected or not on the latest from the sources build.

Glad to see you were on 8.3, so not related to me being on 8.2.

@olivierlambert Gotcha. I'll see if I can get this issue to replicate in my lab at all but so far my backups have been smooth over there.

I'll try to re-create more similar backup jobs in the lab as well, maybe it's a specific setting or something on my jobs.

@olivierlambert Happy to help in any way that I can as well!

Notably, I am not seeing any issues doing backups to SMB or S3 with my lab at home which is on the latest. My lab is XCP-ng 8.3 though, rather than 8.2 like this production setup (which will be getting upgraded to 8.3 now that it's LTS), so maybe something specific with the new backup code and 8.2?

@ravenet @olivierlambert yeah going back to 5.106 seems to have resolved the issue. I want to give it one more day before saying 100% that it did, but all VMs in both my backup jobs last night finished properly.

@olivierlambert I will give this a shot and report back. It may be a day or so, one of the backups is still running (very large VM over S3 so takes a while) but once it's done I will go back and see if the failures go away.

@olivierlambert Good question, I am on Latest by mistake in this environment actually.

Is it safe to roll back to Stable channel even though I am already on latest?

Still seeing this issue, trying to pinpoint it but haven't had any luck. It seems like each VM is about a 50/50 chance if it fails or succeeds, but the logs don't really lead me to anything and there's no consistent reason why it would be happening that I can find.

This is only since going to 5.107.2 as well, wasn't happening on the previous version (which I unfortunately don't recall the version number of).

@olivierlambert This is great, thanks for letting us know! I'll give this a shot in my lab as soon as I can.

Going to give it more time, but restarting all the backups seems to have fixed the issue. Unsure why they would fail once and then resume just fine though.

This is a new one, just updated XOA to 5.107.2 and now my backups are no longer working.

I have support and can put in a ticket, but figured it's better to try here first.

I am getting an error: Fail to connect to any Nbd client on the backups to Backblaze and on my SMB backups I just get a Footer1 !== footer2 error.

What's important here is that it's only about half my VMs, and this is a single host setup, so the NBD client issues don't really make sense to me, unless I'm misunderstanding something about NBD.

Anyone else seeing issues with backups after this update?

Also not seeing anything consistent, not like an issue with Windows VMs in specific, it seems random.

@olivierlambert Yeah so far backups have been fast enough to not pose some huge issue though.

IMO if you have a huge VM (many TB) it should just be dealt with on a NAS or something instead of a VHD.

Still glad that qcow2 is coming though!

@Forza The XOA backup performance is more related to processing and not network, at least as I understand it and have tested.

So I don't think you'll see much of a change there.

@olivierlambert That's a good point about SR-IOV, would be a good workaround if super fast NIC speeds are needed in a guest specifically.

@linuxmoose Yeah testing it is definitely the way to go here, I don't think you'll see very many issues TBH.

It's worth noting that the speeds being seen were still multi gigabit, so again it's not like things are dead slow.

@olivierlambert Yeah and on this note I can say my entire lab is Threadripper, so suffers from the same issue, and it hasn't created any real world problems for me.

@linuxmoose What kind of workloads are you needing network wise though? Like we aren't talking about unusable performance, it's just not as good as Intel.

Unless you're doing higher bandwidth stuff I don't really foresee it posing much of an issue.

@piotrlotr1 Most VMDK's should work, but the V2V tool is really what is meant for this. It lets you warm migrate from VMware to XCP-ng with very little downtime.

@piotrlotr1 Maybe I missed some context in this thread, so apologies if I did.

But the V2V tool should handle this, is there a reason you are wanting to do it as a VMDK import instead?

I've used the V2V a lot and it works quite well.