@techknowbabble said in GRUB waits for confirmation: What did finally work was re-installing with the 'no serial' option and everything seems to be working as expected now. I only have a handful of XCP-NG installations under my belt but I wonder if this is a known bug or if anyone else has had a similar experience. It's not something I've ever seen before and I've done quite a few installations but I can think of some possibilities as to why something like that might fix the problem. My best guess is that there's something built into, connected to, or otherwise in your system that looks like a serial port (maybe even a real serial port) that spits out a character or two into the system at boot time, confusing GRUB and stopping the normal boot process. The bad KVM I mentioned before was doing something like that, throwing a bogus keypress into the system at boot time.

@plaidypus Ah gotcha, this makes sense. I second scaling out instead of up. If you're getting new hosts, I'd also keep in mind newer CPUs do have much higher per core performance (not sure what your current stuff is), so you also might be able to get away with less vCPUs and lower likelihood of NUMA spanning. Either way though I think scaling out is the better direction to go.

@hansve You're welcome.

@apz I see. Thanks.

@R2rho yeah, there are Supermicro systems with AM5 which can handle a decent amount of load, like based on the h13sae-mf, like: https://www.supermicro.com/de/products/system/mainstream/1u/as-1015a-mt (with less depth) Seem to be stable, but we have a small issue regarding onboard graphics ATM: https://xcp-ng.org/forum/topic/9976/black-screen-after-install-on-supermicro-h13sae-mf-with-ryzen-9950x/3?_=1734419502978

You should start by checking the logs. https://docs.xcp-ng.org/troubleshooting/log-files/

Thanks for letting us know, and I'm happy you have thing working nicely now. I think to mark this as resolved you need to convert your original post as a question, and it can then be marked as resolved. I actually cannot do it myself, I think only a few people have the permission to do it for others at Vates.

Enjoy XO & XCP-ng then

@olivierlambert I resolved it, logged in the XCP-ng console and set the NTP servers to default. All good now. Thanks [image: 1733066154172-xcp-ntp2.png]

Preferably after, since the PV drivers contain some VM-specific settings that may be wiped by Sysprep.

@dinhngtu said in Issues with XCP-ng Windows PV Tools 9.0.9000.0 Testsign Pre-release: With 9.0.9000.0, you could sometimes run into this issue if you reboot too early after installing. This will also be fixed in the next release. I just did two more tests and the boot-up failure happened both times. On the last test I waited some time (like 30 to 60 sec) after the driver installation before rebooting (using Windows restart from the start menu). Even though I waited before rebooting I still encountered the boot-up problem: Windows is spinning on this screen and doesn't finish booting: [image: 1732291273907-ef30a370-5897-41e6-a0f1-41fa3720dacb-image.png]

I wasn't aware of this plugin even existing (thanks for the discovery). I'm not sure it's really maintained, but we have a clear goal of getting one officially maintained anyway.

@olivierlambert Which one, powershell or WAC. They are kind of one in the same when you look at how WAC makes the calls to do the work, there's a button to reveal the powershell behind the button clicks so you might be able to get both at once. But WAC draws nice graphs and gives us a GUI to get the work done. Yes I know, real Admins don't use GUI. Whatever, AI will eat our jobs anyway, just trying to stick it out another 9 years at this point. When I get time, I'll still probably take a swing at this task for WAC, because to me this would be valuable. Big learning curve though. Now if MS would finally add Group Policy to WAC and fix some of the DHCP and DNS features that are still in preview...

@dinhngtu Ah thank you! Idk why I couldn't find that on my own, I searched for a while.

According to the documentation, you only need xfsprogs.

I'm not aware of such problem it's like the VM was kept in limbo. You did the right thing with your commands.

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.