Nested Virtualization (X86) Part I - George Dunlap, Xen Server:
https://www.youtube.com/watch?v=8jKGYY1Bi_o

Nested Virtualization (X86) Part II - George Dunlap, Xen Server:
https://www.youtube.com/watch?v=3MxWvVTmY1s

From the UEFI shell use the command: FS0:\EFI\debian\grubx64.efi

It does not fix anything but lets you start Debian manually.

You can also copy that command into /boot/efi/startup.nsh or use GRUB to install the standard UEFI boot files that XCP can use for the next boot.

1. Make sure you have backups.
2. This is supposed to be used shortly after the upgrade, because the version of the XAPI database which will be restored will be that of the backup. If you made changes which affected the metadata stored by XAPI, you may end up with a mismatch between what's really on your storage and what XAPI believes is the current state of VMs, storage, etc.
3. The format for storing UEFI variables for UEFI VMs changed in 8.3 and is not backwards compatible. So UEFI VMs won't start anymore. I'm not sure whether the NVRAM store is converted at upgrade time or only the first time the VMs boot (pinging @BenjiReis about this). Anyway, any UEFI VM whose NVRAM store was upgraded to the format used in 8.3 won't boot anymore when started back on 8.2.1. There are solutions, involving wiping the NVRAM store (which is enough for most VMs, but Debian, notably, may need fixing the boot loader afterwards, using a Live media).

Another option is Warm Migrating VMs from the 8.3 pool to a 8.2.1 pool, using Xen Orchestra, but point 3. above still applies to UEFI VMs.

First, I need to remind all users that Nested Virtualization is not supported even in XCP-ng 8.2.1. It is useful for testing purposes, and we do use it a lot internally (despite its flaws - it can crash badly).

It is not supported within the Xen Project either, because it hasn't yet gotten out of the experimental stage.

This means that workloads running in a VM with Nested Virtualization enabled could theoretically exploit vulnerabilities in Xen and do nasty things, possibly including compromising the host and all its VMs.

This being said, we are aware that Nested Virtualization is a useful feature in various use cases, and are committed to bring it to XCP-ng in an officially supported way in the future.

Now, regarding the current situation: changes made to Xen broke the fragile experimental nested virtualization feature. In a recent talk at Xen Summit, George Dunlap described what needs to be done to make it work, this time in a fully supported way, but now there's a lot of work for developers. In a nutshell, this means that XCP-ng 8.3 likely won't offer Nested Virtualization, even in an experimental way, or at least not at the time of its initial release.

I'll address the topic of downgrading to XCP-ng 8.2.1 in the next message.

I believe I might also be affected by this issue.
I was previously using a Dell 2RU Server 4x CPU's (at work atm, I'll update this post with the exact Dell model and CPU models later as it's powered off at home).

The ''old'' server was running XCPNG 8.2.1, and I was running Truenas as a VM with LSI HBA and nVidia GPU passed through, and Truenas was working like a charm - I was able to use the kubernetes apps, and create nested VM's (although I didnt use them, I was /able/ to, in a pinch).

I recently moved to a Dell R740 with 2 x Intel 6136 CPU's running XCPNG 8.3. These CPU's appear to support all required VT-d (with EPT) extensions, IOUMMU and SRV-IOV.
I've been through the BIOS about a billion times trying to troubleshoot this issue, and have changed the workload profiles and ensured everything relating to virtualisation and performance optimisation is enabled.

However, now my truenas VM displays an error "Virtualization is not enabled on this system", and I'm unable to use the Kubernetes apps, or create VM's from within Truenas. (I have checked and confirmed that the "nested virtualization" option is definitely enabled for that VM.

As a test, I installed a new Truenas VM, with nested virtualization enabled.
After creating the test VM, I can actually click on the Virtualization tab within Truenas, and it doesnt display the same error as before (on the old truenas VM") , but it says your CPU does not support KVM extensions" which I believe to be erroneous.

I can see within this thread that you suspect ""Xen 4.17" is the issue.
Can you provide any steps to 'rollback' to a version that might re-enable the nested virtualization feature to work correctly (or point me in the right direction on how to achieve this?)
Otherwise, is there a supported method to 'downgrade' the XCPNG 8.3 host to 8.2.1?

Please let me know if you require any additional information or if I can be of help testing anything.

(thanks again for all your hard work and amazing free and opensource products! can't wait for the v6 UI :D)

It's not on the top priority list as right now, as 8.3 is coming closer and especially this Friday there's XO 5.95.
However, next week, we are at the Xen Summit, so that will be the occasion to discuss with both Vates (@andSmv @marcungeschikts ...) but also Xen upstream directly

Can normal cold migration be forced to work? May be as a check box/warning option that features might not be available (like TPM)?

vm.migrate
{
  "vm": "654cc5c6-7e50-fc28-ecc4-fe46929905b2",
  "mapVifsNetworks": {
    "2db4235a-345f-f286-4172-77dab4e198fe

": "8e969c1a-cafa-7ac0-504d-cf5cd19ef1e4

"
  },
  "migrationNetwork": "8e969c1a-cafa-7ac0-504d-cf5cd19ef1e4

",
  "sr": "a25ba333-a1a5-f22f-c337-0ec662e835ed",
  "targetHost": "ca60fce7-924a-45f9-a1c6-ee860952e6aa"
}
{
  "code": "NO_HOSTS_AVAILABLE",
  "params": [],
  "task": {
    "uuid": "57fe6efb-569e-3fa3-a345-d43377260884

",
    "name_label": "Async.VM.migrate_send",
    "name_description": "",
    "allowed_operations": [],
    "current_operations": {},
    "created": "20240510T10:45:50Z",
    "finished": "20240510T10:45:51Z",
    "status": "failure",
    "resident_on": "OpaqueRef:99de1bb8-8e7f-e79a-d7f9-5d84c2c09a73",
    "progress": 1,
    "type": "<none/>",
    "result": "",
    "error_info": [
      "NO_HOSTS_AVAILABLE"
    ],
    "other_config": {},
    "subtask_of": "OpaqueRef:NULL",
    "subtasks": [],
    "backtrace": "(((process xapi)(filename ocaml/xapi/xapi_vm_placement.ml)(line 106))((process xapi)(filename ocaml/xapi/message_forwarding.ml)(line 1453))((process xapi)(filename ocaml/libs/xapi-stdext/lib/xapi-stdext-pervasives/pervasiveext.ml)(line 24))((process xapi)(filename ocaml/libs/xapi-stdext/lib/xapi-stdext-pervasives/pervasiveext.ml)(line 39))((process xapi)(filename ocaml/xapi/helpers.ml)(line 1506))((process xapi)(filename ocaml/xapi/message_forwarding.ml)(line 1445))((process xapi)(filename ocaml/xapi/message_forwarding.ml)(line 2537))((process xapi)(filename ocaml/libs/xapi-stdext/lib/xapi-stdext-pervasives/pervasiveext.ml)(line 24))((process xapi)(filename ocaml/libs/xapi-stdext/lib/xapi-stdext-pervasives/pervasiveext.ml)(line 39))((process xapi)(filename ocaml/xapi/message_forwarding.ml)(line 2559))((process xapi)(filename ocaml/xapi/rbac.ml)(line 189))((process xapi)(filename ocaml/xapi/rbac.ml)(line 198))((process xapi)(filename ocaml/xapi/server_helpers.ml)(line 75)))"
  },
  "message": "NO_HOSTS_AVAILABLE()",
  "name": "XapiError",
  "stack": "XapiError: NO_HOSTS_AVAILABLE()
    at Function.wrap (file:///opt/xo/xo-builds/xen-orchestra-202405091612/packages/xen-api/_XapiError.mjs:16:12)
    at default (file:///opt/xo/xo-builds/xen-orchestra-202405091612/packages/xen-api/_getTaskResult.mjs:11:29)
    at Xapi._addRecordToCache (file:///opt/xo/xo-builds/xen-orchestra-202405091612/packages/xen-api/index.mjs:1029:24)
    at file:///opt/xo/xo-builds/xen-orchestra-202405091612/packages/xen-api/index.mjs:1063:14
    at Array.forEach (<anonymous>)
    at Xapi._processEvents (file:///opt/xo/xo-builds/xen-orchestra-202405091612/packages/xen-api/index.mjs:1053:12)
    at Xapi._watchEvents (file:///opt/xo/xo-builds/xen-orchestra-202405091612/packages/xen-api/index.mjs:1226:14)"
}

(targetHost above is a common native XCP-ng host)