I run latest NethServer as a VM on my unRAID server.
I have noticed this months ago, but to be honest never bothered to report it (it is minor).
I have noticed that if I set NS machine to use anything newer than Q35-4.2, it freezes after a few minutes/seconds.
It boots the system, it enabled the web interface, but then console is frozen (cursor static) and web interface dies.
It is not an issue to keep this machine with Q35-4.2, but if it is something that can be fixed, why not.
Thanks.
I still wonder if it is related to specific host hardware or specific NS services running (“pushing” the virtual chipset in the right places)…
As said and shown in the screenshots, I’m using Q35 / 60(+)…
It could be the KVM implementation in UNRAID uses an older Version than my Proxmox (Top up to date!)…
Note: I’m using a KVM-64 CPU here, not “host”…
This should make the hardware practically negliciable, this even allows a Windows10 to run with an AMD or Intel underneath - no blue screens!
Windows does not even realize the CPU has changed…
A good idea may be to find out the used versions - I’ll need to check what Proxmox is using…
As to the VM:
So far nothing unstable…
With 4 GB RAM and 4 CPU cores (The hardware is a almost 10 year old HP Proliant ML110 G7…) it’s quite fast, too.
My 2 cents
Andy
Packet Versions used by my Version of Proxmox (7.0.13):
The reason why I use KVM64 for all my 30 clients and almost all VMs (Only one exception: nested Virtualization of VMware ESXi in Proxmox to run 2 Novell Netware servers my client needs for legal reasons (archive available)) is that this increases flexibility, especially for Windows systems.
This enables me to live migrate VMs between almost any hardware without issues, like Windows needing reactivation or relicensing…
I am having second thoughts on switching to QEMU64 CPU (maybe I will for testing only), as I really care more about not having a CPU bottleneck or limiting my CPU flags (UNRAID doesn’t allow configuration of QEMU64 emulated CPU at least through GUI - proxmox is specialized in VM hosting), than using a new version of the (same) emulated chipset.
I might do some testing in the weekend though to see if we are looking at the right direction.