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

@olivierlambert right that makes sense. More so what I meant is, if you have a VM you want to migrate to another host, but that VM has a backup job (and therefore at least one snapshot since the backup jobs require there to be a snapshot at all times), then you can't migrate that VM.

So seems to me like backups and VM migration abilities sort of conflict with each other.

Or maybe there's something I'm misunderstanding here.

@olivierlambert OK this makes sense.

Though it does bring up 2 thoughts:

• If backups require a snapshot to exist, how would one migrate a VM that has any associated backups?
• I think the error should be more descriptive than the CBT error I mentioned above

Thanks for the help here!

@olivierlambert Yes, it does. I should've noticed that, woops.

Is it not possible to migrate a VM with any snapshots at all or?

I'm a little lost on this one, and feel like maybe I'm missing something (went back through some previous blogs posts about CBT but didn't see anything related to this and the error doesn't appear on any google searches).

In my lab, I have a VM I am trying to migrate while powered off and it's giving me the below error whenever I do it.

},
"start": 1762284957343,
"status": "failure",
"updatedAt": 1762284960438,
"end": 1762284960438,
"result": {
  "code": "VDI_CBT_ENABLED",

Any clue what this means? CBT is actually NOT enabled for this particular VDI either.

My XO is on the latest commit (58f02), hosts are all on 8.3 but don't have the most recent patches yet.

What GPU do you have? I thought I read something about NVidia's newer stuff having vGPU without the expensive licensing and hardware. But it's possible I'm just conflating that with the increase in concurrent NVENC encodes.

On the bright side, you can always get a cheap GPU and just do passthrough with it. I do that for my Jellyfin server with a 2060, it's very easy to do in XCP-ng now and works super reliably.

Did a little digging and I don't think I've seen anything about this on the forum before so wanted to post.

Does anyone know how Xen Orchestra behaves if you add an encryption key to a remote after said remote has already been used for unencrypted backups?

I'm planning to start encrypting everything I upload in the near future, if it's as simple as adding a key that's great, but I am guessing it's better to create a new remote (and new bucket) and then just restart all the backups with the new remote?

Or should I re-create the backup jobs entirely?

@DustinB Yeah I thought about doing something like this, but then we are getting into overkill costs lol.

My main point behind this post was to get info on what other people are doing, I presumed most are just relying on config backups and will restore it at the other site if needed, which is fine.

I was just also debating about whether or not I wanted the subnets to match between these 2 sites, since that can create some routing headaches, but should still be doable and would make recovery even faster.

@olivierlambert yeah I do use that feature, so that's very helpful! Should make this all doable.

@Andrew Yeah so I hear you on this, and it all makes sense, I've recovered XO plenty of times in my lab.

But, it still feels more complicated than it needs to be and I feel like there has to be a better solution in place. The idea with disaster recovery sites is relatively quick failover (even if manual). Having to restore XO, then reconnect it to all the servers, reconfigure it's IP addresses, etc... feels like it's more work than it should be to do a restore. Not to mention accessing the other cluster assuming something like complete natural disaster destruction at the primary site.

As for backups, yes, I manage a lot of infrastructure like this, not a noob by any means I promise lol, I'm just trying to improve the way I am going to do this in the future, if possible.

Restoring XOA at another site and then reconfiguring it entirely seems like a lot of work.

This is something I've put a lot of time into recently but am still not quite sure the #1 way I would go about doing it.

If XOA is hosted at one physical site, and you're planning for the possibility of that site collapsing completely, how do you go about managing other remote sites with XOA?

Mostly posting because I am curious how others are architecting this.

Thinking for me I will mostly just have XOA itself replicated and can power it on at another site if ever need be. I think the complication comes into IP addressing and the like though, since the other site might not have the same subnet layout.

@Bastien-Nollet Thanks as always @florent