I was thinking more of updating the entire set of the agent and drivers, similar to how XenServer VM Tools for Windows have it implemented. Using a scheduled job, they regularly check whether an update is available, and if so, they carry out the update of both the agent and the drivers themselves.

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

@dinhngtu said in XCP-ng Windows PV tools announcements:

@abudef Got it, the agent was not changed since the last version so the build number was not bumped. I'll keep that in mind for the next release.

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)"
}

@AlexanderK said:

@abudef this causes some vms not to boot

You mean that when you enable Nested virtualization in the VM settings under the Advanced tab, the VM then fails to boot?

@MajorP93 Overall it works, Windows VMs run more or less reliably, but I wasn’t able to resolve the nested host crashing when starting Debian. That’s why I put the free version of ESXi underneath the nested XCP-ng hosts, and that works reliably.

@MajorP93 Sure I did

You can enable it in the VM configuration simply by clicking a button in Xen Orchestra:

or use this command:
xe vm-param-set platform:nested_virt=true uuid=<VM UUID> mistake here, see below

Nested virtualization doesn’t work very well in Xen. For example, when I set up a small test playground, I had XCP-ng 8.3 as the primary host and another XCP-ng running on it as a nested host. When I then booted Debian 12 on the nested host, it caused the entire nested host to crash and reboot. On the other hand, Windows VMs on the nested host run quite well.

Later, when I was preparing a test lab, I installed ESXi 8.0U3e on a Dell server and then deployed four virtualized XCP-ng 8.3 hosts on top of it. A number of Linux and Windows VMs run on them without any issues.

@gduperrey Of course, the order matters. Now everything seems to be clear.

In my case, I gave the command to shut down all hosts, and the master "made it" first. The other hosts then got "stuck" at this point for a very long time:

EDIT: Apparently waiting for umount:

@gduperrey Restart happens normally, without any noticeable delay, but shutdown takes a long time. Which logs should I specifically check?

(It's not a real issue, but I just needed to move servers in the lab and had to shut them down, so I noticed it.)

Hi, it seems that shutting down the host is taking an extremely long time now. I tried it in two different environments; the shutdown process starts but gets stuck on the splash screen for several minutes before finally completing. There were no active virtual machines on the hosts being shut down.

Does anyone have the possibility to test this in a lab? Thanks!

Hi,
I’m afraid I’ve encountered the same problem:

• Xen Orchestra, commit 0b52a
  

• v6