@olivierlambert Thanks for the good news!

I've used VMware for years. ESXi as a server hypervisor and VMware Workstation Pro on the desktop. Even for some labs and test environments I got by with the free version of ESXi with limited APIs. The new licensing policy does not suit me and my companions at all and as a bonus Broadcom has cut the free version of ESXi. Bravo! I think Broadcom should get the award for best marketing of XCP-ng, H-V, Citrix etc. for 2024

On desktops, I need to keep VMware Workstation Pro for many reasons. That's why I was impressed by the videos @lawrencesystems made about XCP-ng & Xen Orchestra. The capabilities that are close to vSphere and vCentre, the ability to import and export VMDK so easily through XO blew me away. And to top it all off, transferring VMDK disks through XO works noticeably faster than migrating VMs between VMw WS and ESXi!

Great, it's working fine now

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.

That's exactly it, thank you

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

@stormi That's not quite what I meant. The point is that if the host is 8.3/4.17, then virtualization is not working on its guest and therefore no other nested guest can be started on this guest. And actually, yes, if 8.3/4.17 appears somewhere in the cascade of nested hosts, then nested virtualization will no longer work on its guest.

But I have a suspicion that it hasn't worked since the last or second to last batch of updates for XCP-ng, that it worked before.

Hello,
on XCP-ng host v. 8.3 (latest updates), I created an XCP-ng 8.3 virtual machine using the CentOS 7 template and enabled Nested virtualization. However, XO shows a "Hardware-assisted virtualization is not enabled on this host" alert and the nested virtual machine cannot be started on the virtualized host.

vm.start
{
  "id": "b2b6c96b-f6c8-a99c-5e72-d6cd1b123022",
  "bypassMacAddressesCheck": false,
  "force": false
}
{
  "errors": [
    "xcp-ng-brxbamkk: VM_HVM_REQUIRED(OpaqueRef:e0855019-e6dd-595d-648c-62872961b97f)"
  ],
  "code": "NO_HOSTS_AVAILABLE",
  "params": [],
  "message": "NO_HOSTS_AVAILABLE()",
  "name": "Error",
  "stack": "Error: NO_HOSTS_AVAILABLE()
    at Xapi._startVm (file:///opt/xo/xo-builds/xen-orchestra-202404302058/packages/xo-server/src/xapi/index.mjs:909:11)
    at Xapi.startVm (file:///opt/xo/xo-builds/xen-orchestra-202404302058/packages/xo-server/src/xapi/index.mjs:948:7)
    at Api.#callApiMethod (file:///opt/xo/xo-builds/xen-orchestra-202404302058/packages/xo-server/src/xo-mixins/api.mjs:366:20)"
}

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

@DustinB said in Cannot import ISO file:

What version number were you at before (while it wasn't working) and when you downgraded what version were you at?

Now I tried again and it still doesn't work in commit 1b5157e, but it works in 0ccfd4b. I didn't check which specific commit introduced the problem with the self signed certificate.

The array was created later after installation manually using unused disks. And then it was connected in the normal way as a local SR using XO.

It would be nice if it would also handle the state of other mdamd RAID arrays. After all, the All mdadm RAID are healthy message kind of predetermines it

Yeah, that's it, thanks.

device = '/dev/md0'

@andriy.sultanov said in XCP-ng 8.3 updates announcements and testing:

does this reproduce if you reboot again

Yes, this does. Logs have been provided via pm.

[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 ~]#

@stormi No stats until the toolstack restarts, as with previous candidates

@olivierlambert
8.3 including todays candidates

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

Hi,
In XO from source commit ab569, the tags I'm using don't appear in the pick list.

In XOA, they are available in the pick list

Any idea?

Under what circumstances is the RAID array status displayed here? I have an mdadm RAID array on my host (dom0), but here it says "No RAID information available":

@XCP-ng-JustGreat Until this is fixed, you need to restart the toolstack after each host restart, which is not often done, so it's not really a problem.