Hi,

It's a very vast question, but in a way, yes, you can achieve a similar result. OpenStack is directly design with the public cloud in mind, XO is not. However, you can leverage the API and even use existing features to enjoy something that can answer your needs.

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

@WayneSherman

Thanks for this.

@spcmediaco

FYI, I never figured out how to fix. I am doing backup recovery now.

@dinhngtu It happened again to me.... Windows 10 22H2 on XCP 8.2.1...

Same issue as others. Windows reports a USB driver issue. Disabling/re-enabling the windows driver makes it work again.

To answer your question, Yes, reverting to a snapshot with memory keeps the problem of a failed USB/mouse.

@Bambos A timeout error means that the host did not reply in the expected delay, which, if I'm remembering correctly is 5 minutes.

I suspect a problem on your host but we will take a look further on your support ticket.

@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

xcp-ntp2.png

I have yet to successfully reboot a host from XO. I have tools installed on three out of four VM. I try shutting down the VM without tools, then issue reboot host in XO GUI. Get warning:
Some VMs cannot be migrated without first rebooting this host. Please try force reboot.

Is this a setting perhaps?

I'm always needing to shutdown all VMs before I can reboot the host. It is a single host environment, so there will never be an available server to migrate VMs to.

Rebooting in XSCONSOLE causes the host to be unavailable in XO. I have to remove then add the host back in XO.

Can anyone shed light as to what I'm doing wrong?

Do I just need to always run the following after a reboot?
xe host-enable host=xxxx

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:
ef30a370-5897-41e6-a0f1-41fa3720dacb-image.png