Hello, I've tried benchmarking several Windows VMs from another client and am getting expected performance: Read: .\diskspd.exe -c1G -d10 -Su -Sw g:\data.dat Write: .\diskspd.exe -c1G -d10 -Su -Sw -w100 g:\data.dat Windows Server 2022: Read IO thread | bytes | I/Os | MiB/s | I/O per s | file ------------------------------------------------------------------------------ 0 | 1151533056 | 17571 | 109.72 | 1755.53 | g:\data.dat (1GiB) ------------------------------------------------------------------------------ total: 1151533056 | 17571 | 109.72 | 1755.53 Write IO thread | bytes | I/Os | MiB/s | I/O per s | file ------------------------------------------------------------------------------ 0 | 966000640 | 14740 | 92.12 | 1473.98 | g:\data.dat (1GiB) ------------------------------------------------------------------------------ total: 966000640 | 14740 | 92.12 | 1473.98 Windows 11 24H2 (with Eset): Read IO thread | bytes | I/Os | MiB/s | I/O per s | file ------------------------------------------------------------------------------ 0 | 1100283904 | 16789 | 104.81 | 1677.01 | g:\data.dat (1GiB) ------------------------------------------------------------------------------ total: 1100283904 | 16789 | 104.81 | 1677.01 Write IO thread | bytes | I/Os | MiB/s | I/O per s | file ------------------------------------------------------------------------------ 0 | 931594240 | 14215 | 88.82 | 1421.07 | g:\data.dat (1GiB) ------------------------------------------------------------------------------ total: 931594240 | 14215 | 88.82 | 1421.07 Several questions: Are you running benchmarks on a separate virtual disk? If not, could you try again using a share created from a separate virtual disk? Could you run CrystalDiskMark locally on these VMs and see the performance? You mentioned that Eset security takes up 100% CPU during the benchmark. Could you try temporarily uninstalling Eset and testing again?

Thanks for your feedback. In the meantime, I will plan a "spike" to investigate the status of USB speed on passthrough.

@andsmith windbg is also a regular win32 app and is included in any recent windows SDK. Here: https://developer.microsoft.com/en-us/windows/downloads/windows-sdk/ You just need windbg so deselect all the other crap.

Yes, you can use XO webhooks (IIRC) to trigger something before or after a backup and send the request to a custom agent you made inside the VM. But I'm not sure to get it, can you provide what do you want to achieve, not the technical solution (script VM backup is already a solution, not the problem you are trying to solve)

@andrewperry The release notes warn about PV guests.

@PimAarts hi! Thx for the report - I reproduced the issue and am investigating. Meanwhile clicking on Cancel will give you access to XOLite

2 times the charm I have no idea why it failed initially, but at least you tested the magic rollback As you can see, it's really a GREAT feature

We are now live again with all the VMs - which is a relief. The above steps from @stormi were great, the one thing I notced was the /etc/stunnel/certs directory didn't exist. I created that manually and everything else seemed happy. I did have to mess about a bit with the fibre NICs, but I've repeated the previous renaming and that's now running fine. Thanks very much for all the help - I appreciate it.

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.

@elvintmp75 I should have searched forum better lol. Because it’s UEFI the file is in a different location https://xcp-ng.org/forum/post/11939

@randyrue Confirmed that after cold booting a VM to a new host I can then migrate it live to another new host.

I see that the bug is actually already fixed on the latest version (5.98.1).

I believe Proxmox Backup Server kernel Linux pbs 6.8.4-2-pve has also the same issue. updating to Linux pbs 6.8.12-1-pve solves.

@darkbounce Short answer: it seems that Intel hybrid architecture is finding a way to make something that would result of Xen running the VM with the less "featured" CPU, meaning your VM will never use all P core instructions that aren't on E core, meaning... it will work without disabling one or another. Hard to tell how much is lost in terms of perfs vs the best Intel hybrid scheduler (which is on... Windows) but probably not that much on a machine with a reduced number of P cores like this one.

@yammy I hope you are not talking of installing Docker in the Dom0, because this is really a bad idea.

@Pix [image: Capture d’écran 2024-08-23 à 16.36.56.png] Looks like the different HW or Pool is an issue, i'll make more tests and report here if it's ok

@PontusB i don't even know if disabling option 66 solves the issue but as soon as we add option 66 in our DHCP server it boots fine from XenServer (but without HA between the many PVS servers).

@stormi Thanks, looking forward.