@jasonnix I've done extensive testing with this myself, first and foremost, Veeam is the one that would have to support it, not vice versa.

Second, it would be best to use XO for the backups, it's much more fluid and is fully integrated, I've been doing this for some time and it's been excellent in multiple production setups.

I also have tested using Veeam via agents within the VMs themselves (this was just for test purposes, I'd still not really recommend it) and it worked exactly as expected.

Using XO for this is still better though, it's generally faster, easier to setup, more reliable, and much faster and easier to recover from backups.

If you are considering this as a comparison to VMware, it's worth noting that it's not really a positive thing that VMware requires you buy a separate product entirely in order to handle backups.

@Bastien-Nollet Thanks as always @florent

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.

Figured it out after some digging, appears it's related to Netbox having ipv4 translated into ipv6 for that field, so to use IPv4 you have to have :ffff:x.x.x.x/128 as your IP address (the x's being your octet).

Once you do this it works without issue.

@olivierlambert Oh yeah good point, that makes sense.

Well I think I've got all my answers now, thank you!

I can confirm this is the case for me too, not a huge deal, but would be kinda nice if it could keep track of the name.

@olivierlambert Yup, I've had exactly that a few times, usually on used boards.

@R2rho if possible, however annoying, I would also take the CPU out and check for pins on the motherboard being bent with a flashlight.

IIRC the templates help define some of the UEFI specs and things like that, generally speaking though using something similar to what you're deploying, even if not the same version (i.e. Ubuntu 20.04 template for a Ubuntu 23.10) should be functional, at least in my experience this has never created an issue.

@Bastien-Nollet I somehow missed the email about this.

But wanted to come say thanks on this thread anyway. The update fixed the issue, great work!

@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.

@MajorP93 This was also my thought, the disconnection method you mentioned, I was just wanting some feedback about that.

I do have to be a bit careful because the migration must happen and then the VM on VMware must go back online while I work with the vendor to migrate all the rest of the data.

As for the bigger than 2TB issue, that won't be an issue for me. This VM is HUGE but it's because it's thick provisioned and no longer needs to be, the new VM will have like 8 disks but none of them will be over 2TB (most will be less than 100GB).

So I am thinking using V2V and just powering off the VM on VMware, disconnect the unneeded VDIs, then migrate, then reconnect those VDIs and power the VM back on.

@Pilow Yeah this is also an option, and then just export it and copy it over to XCP-ng. I was just wondering if there was a more proper way to go about this that Vates recommended.

It's been a minute since I migrated anything from ESXi to XCP-ng, but I'm going to be doing this in a production setup again fairly soon.

This one has been rather challenging since the VM in ESXi is 16TB, but we only need to migrate the C drive which is 100GB.

Is the best route to do this just to export the VMDK and import that into XCP-ng? Wasn't sure if the newer migration tools had options to select which disks to import and things like that.

@florent As it turns out, the job completed the next time it ran and this task went away, not sure why that first one failed but it seems to be OK for now.

I will update this if I see this error again and be sure to include as many logs as I can.

Thanks as always!

I updated an environment over to 6.0.3 over the weekend, it worked fine for my first 2 nightly backups, but the one from last night failed for most of my VMs.

Specifically, the backup to Backblaze B2 failed, our SMB backups worked just fine.

The error I am seeing on the backup is "the write IncrementalRemoteWriter has failed the step writer.beforeBackup() with error . It won't be used anymore in this job execution."

I then also noticed that, for one of the failed VMs, there is a pool task stuck for "Exporting content of VDI (VDI name) through NBD" and it's stuck at 43% and hasn't moved at all for a while.

The XOA VM is also not using a lot of bandwidth or anything so I don't think it's actually backing up this VDI anymore but it's also not cancelled.

I have a host that crashes once in a while, it's just in a lab so not mission critical but I so far haven't been able to figure out why.

It's been doing this for I think about 2 years now and it's entirely random when it crashes, sometimes it'll go 6 months without an issue and other times it crashes nearly back to back.

Anyway, I do have crash logs in the /var/crash but I'm not sure the best ones to start digging through first, any suggestions based on the photo available here?

Sorry, not a log expert and since this isn't mission critical I'm happy to dig for a while.

The host running this is an AMD Threadripper 1950X from a long while ago, it was stable on Windows 11 like 5 years ago but of course that doesn't mean it hasn't developed an issue.

I guess in "short" since I ramble a lot, I just want to know which of the crash logs to start sifting through first and maybe an idea of what types of things I should be looking out for?

Figured it out after some digging, appears it's related to Netbox having ipv4 translated into ipv6 for that field, so to use IPv4 you have to have :ffff:x.x.x.x/128 as your IP address (the x's being your octet).

Once you do this it works without issue.

I configured Netbox sync in an environment today, and after I did everything by the book, I got a 403 forbidden error. I figured this was odd since I've done this before without any issues and was really sure I followed it all identically.

Anyway, after some digging, I realized the sync did work it just threw the error anyway.

I am seeing the "Source IP x.x.x. is not permitted to authenticate" but the API key I have setup is indeed set to allow the XOA IP address.

Any idea what would cause this? It's odd to me to see a 403 response when the sync absolutely worked.

Nothing has changed since the initial sync so I can't so for sure if it'll keep syncing OK or not, but it definitely worked the first time and did show the 403 error.

@florent OK gotcha, I figured this was the case.

So best option would be to create a new backup job, encrypt that to a new remote, then go back and delete all the old stuff when ready?

@olivierlambert Oh yeah good point, that makes sense.

Well I think I've got all my answers now, thank you!