@Byte0 I think this is a fair use case, containers are a bit different and what you described is basically how containers work on most setups. I mean K8s on XCP-ng works that way, you deploy VMs which then have containers running inside them.

So not quite the same as nested virt.

@Chuckz wouldn't the better solution here be to prioritize making Core Isolation work within XCP-ng guests rather than focusing on nested virtualization?

Nested virt has other issues and again should not really be used with high priority VMs.

I guess that's the whole thing I'm getting at, nested virt isn't the fix for this specific issue.

@Chuckz Why do you need Core Isolation enabled in a VM? Core Isolation is designed to protect processes within Windows 11 by using VBS, if you're already isolating the VM I don't see a huge reason to have it enabled.

It's worth noting again that Microsoft themselves says to NOT use Nested Virt for production use, very specifically in their own documentation.

I get what you're wanting here but reality is 99% of places don't need nested virtualization and if they do they should probably rethink it since it's not considered stable or production ready on ANY hypervisor. This isn't specific to XCP-ng.

Hyper-V has probably the best nested virt support and even they say it should not be used in production environments.

I'm not saying I don't want this feature to work better, I do. But I can't imagine it should be a priority for Vates or anyone working on Xen because it's not really needed for production setups.

If I am missing some reason you have to have this enabled please let me know, but virtualizing Windows just to nest another Windows so you can enable Core Isolation is really cumbersome and not worth any benefits it provides as far as I can tell.

@Chuckz Yeah it would be a nice feature to see. I think the issue though is how much work it takes when it's not something anyone should be using in production. It's really just a heavy homelab feature.

I want it to work, don't get me wrong, but no big org should be doing nested virt, it's just not a good idea and even Hyper-V recommends against it.

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