So it looks like it was a browser cache problem, solved by deleting it.

[18:38 vms04 ~]# xe host-call-plugin host-uuid=5f94209f-8801-4179-91d5-5bdf3eb1d3f1 plugin=raid.py fn=check_raid_pool {} [18:38 vms04 ~]# [18:38 vms04 ~]# cat /proc/mdstat Personalities : [raid0] md0 : active raid0 sdb[1] sda[0] sdc[2] 11720658432 blocks super 1.2 512k chunks unused devices: <none> [18:56 vms04 ~]# mdadm --detail /dev/md0 /dev/md0: Version : 1.2 Creation Time : Fri May 2 14:43:06 2025 Raid Level : raid0 Array Size : 11720658432 (11177.69 GiB 12001.95 GB) Raid Devices : 3 Total Devices : 3 Persistence : Superblock is persistent Update Time : Fri May 2 14:43:06 2025 State : clean Active Devices : 3 Working Devices : 3 Failed Devices : 0 Spare Devices : 0 Chunk Size : 512K Consistency Policy : none Name : vms04:0 (local to host vms04) UUID : bbdc7253:792a8ada:ee21a207:4b8d52d2 Events : 0 Number Major Minor RaidDevice State 0 8 0 0 active sync /dev/sda 1 8 16 1 active sync /dev/sdb 2 8 32 2 active sync /dev/sdc [18:56 vms04 ~]#

Ping @thomas-dkmt

Looks to be correct on the current release of XO from Source and reads as "Prevent Migration"

Hi, You can use delay or if you want specific order, you need to use vApp, that you can configure with the CLI. See https://docs.xcp-ng.org/appendix/cli_reference/#appliance-commands

@tjkreidl We don't need performance, but we do need to test how XCP-ng pools, networking, migration, live migration, backup, import from VMware and so on work. It's just a playground where we can have relatively many XCP-ng hosts, but it's not about performance, it's about efficiency and low requirements, because it's just a playground where we learn, validate how things work, and prepare the process for the final migration from VMware to XCP-ng. We originally had two R630s ready for this, then 4, but that would have been unnecessary, given the power consumption, to have physical hypervisors, so in the end we decided to virtualize it all. Well, on ESXi it's because XCP-ng works seamlessly there in nested virtualization.

This requires some extra plugins to be able to do it, and as it's rather "advanced"/not usual for the main XCP-ng use cases (which is connecting to iSCSI/NFS/shared storages, it's not a priority. Which doesn't mean it's not a good idea or interesting, but there's some work to do it and then to maintain it.

qemu-img convert disk_image_fixed.vhd -O vpc -o subformat=dynamic disk_image_dynamic.vhd

@abudef Indeed, the delay is in milliseconds.

Great, it's working fine now

Usually this error is caused by the merge process still running in the background from a previous backup job.

That's exactly it, thank you [image: 1717165046697-1533660b-c0eb-45b1-b81c-ae50d03a4f36-image.png]

Hi, It's not possible.

There is some diff, but not that much between HyperV, ESXi and Xen. However, it's big enough to require a lot of effort to get nested working correctly, one small mistake and your VM is dead.

@lawrencesystems I think this is quite common when you need to test certain scenarios with multiple hypervisors (backup, migrations, etc.). You only need a couple of HVs with a few tiny running VMs. We have done this setup with nested esxi many times for testing purposes. And since e.g. Ubuntu and Windows work this way, the problem is probably specific to Debian (and maybe others?).

Solved by 583c728

Solved by 583c728

To conclude this: @florent and I discussed the issue in a private conversation. I provided the vmdk file that was causing the problem. It turned out that the problem was caused by the vmdk thin file from VMware Workstation Pro, which has a slightly different structure than the vmdk files on ESXi hypervisors. Currently XO imports these files fine and the problem can be considered solved. Thank you very much @florent for your cooperation and help.

@abudef I ran into the same thing on a dell latitude 5411, but I eventually found a workaround. In the BIOS under System Configuration there was an option called Unobtrusive Mode, and when enabled, a specific key combination will turn off the display and speakers, independent of the OS. The same key combination will then turn them back on when needed. While an automatic feature would be preferable, the manual option meets my needs since it would be rare to need to use the laptop screen. The one downside for me is that if power is lost long enough that the battery drains, the screen will need manual intervention after power is restored - the BIOS will turn the machine back on when it receives power, but won't put the screen back in its previous state. I put a sticker on the laptop with the key combination so I will remember it when needed.