March 31, 20179 yr I'm a beginner in unRAID's virtualization world, but I managed to successfully run one unRAID server with virtualized gaming machines in it (the link with the details is below). But after having problems with stability of GPU passthrogh (in short, only Q35+OVMF+Win10 works in my case) I again ran into some issues. Sometimes I turn off my unRAID server just to save electricity and sometimes, after I turn it back again, VM's perfomance turns out to be severely decreased. It happens from the start of the VMs and the only one thing that helps is turning the server off-on again (and sometimes I have to do it twice and even thrice). I have two Windows VMs and one pfSense VM at the moment, and both Windows VMs are affected (don't know how to check pfSense). Perfomance drop involves: 1. Laggy and stuttery Windows applications - i.e. Chrome starts way slower. 2. Severe issues with games: FPS is 3-5 times lower, some games take eternity to start. 3. CPU-Z clearly shows score decrease: normal score for one core is 1600-1700, decreased - around 500. Sometimes when run in that VM state CPU-Z hangs up the VM. Doesn't matter if VMs were started by autostart or were run one by one manually. Restart of a VM doesn't help, only turning the whole server off-on. It started roughly at the same time I added pfSense machine. But there's no any logic in that and even if pfSense off (autostart is off), I still get decreased performance in Windows VMs with the same chance. Logs don't contain any errors. Just some info abt my server and issues I had before:
March 31, 20179 yr isolate your vm cores away from unraid. read the cpu pinning thread at the top of this forum.
March 31, 20179 yr Author 35 minutes ago, 1812 said: isolate your vm cores away from unraid. read the cpu pinning thread at the top of this forum. Isolated all cores but the first pair, and it didn't help, sorry. Got decreased performance just after reboot.
March 31, 20179 yr Author 1812, Done (SPC was the only VM running, performance was decreased). srv-diagnostics-20170331-0515.zip
March 31, 20179 yr This probably has something to do with it Mar 31 05:06:20 SRV kernel: TSC synchronization [CPU#0 -> CPU#1]: Mar 31 05:06:20 SRV kernel: Measured 315100525287432 cycles TSC warp between CPUs, turning off TSC clock. Mar 31 05:06:20 SRV kernel: tsc: Marking TSC unstable due to check_tsc_sync_source failed Mar 31 05:06:41 SRV kernel: kvm: SMP vm created on host with unstable TSC; guest TSC will not be reliable Assuming this is the problem, I do not know the fix.
March 31, 20179 yr Author 1812, ty for taking a look at my logs! Unfortunately I always get these lines in the syslog. Here's the diagnostics file after turning off-on the server, VM is running perfectly, but the lines are still there.
March 31, 20179 yr your libvert logs in both instance show 2017-03-31 10:13:44.234+0000: 3169: error : x86FeatureInData:780 : internal error: unknown CPU feature __kvm_hv_spinlocks 2017-03-31 10:13:44.234+0000: 3169: error : x86FeatureInData:780 : internal error: unknown CPU feature __kvm_hv_vendor_id this was brought up by someone with similar hardware here: I think somehow the unstable clock may be causing the problem, the more I read online. And it may just be inconsistent when it causes the problems. The workaround I proposed in that thread, switching from host passthrough to emulated might help, or not at all. I also saw someone online saying that changing their topology definition in the vm helps with the instability. Instead of presenting the vm a virtual hyper threaded processor, changing the xml to the following presents just an 8 core processor. <topology sockets='1' cores='8' threads='1'/>
March 31, 20179 yr Author Thank you! I'll try both workarounds you offered and report the results. But something tells me that it isn't a state of a VM - looks like it's more related to the server itself, because if I'm getting this issue after server restart no matter what I try, how I restart VMs, it won't go away until I turn the server off and on again.
Archived
This topic is now archived and is closed to further replies.