JuliusZet

Here is a temporary solution until limetech has implemented this feature:

Hey everyone! I have found an easy solution how you can both set a custom port and a password for VNC at the same time: Shut down the VM. Edit the VM and switch to XML View. Search for the <graphics type='vnc' ...> element. Set the autoport attribute to 'no' and change the attributes port and websocket to any unused ports. The line should now look something like this: <graphics type='vnc' port='5900' autoport='no' websocket='5700' listen='0.0.0.0' keymap='de'> Append the attribute named "passwd". The line should now look something like this: <graphics type='vnc' port='5900' autoport='no' websocket='5700' listen='0.0.0.0' keymap='de' passwd='Cd8B8fmCehbdaFLfCsfZyTL6'> Click the Update button at the bottom of the page to apply the changes. Start the VM. You might notice, that the "passwd" attribute and value are no longer visible, after you clicked the Update button. But looking at the XML file itself from the console reveals, that they are actually there. (You can type "cat /etc/libvirt/qemu/your-vm-name.xml" into console to verify that.) I assume, that the unRAID Web GUI hides the "passwd" attribute and value for security reasons. This is however not an ideal solution, because every time you want to change a setting you would have to do this again. @limetech, it would be great, if you could add an option to change the VNC port of a VM from within the Form View. This would fix the issue.

bump same issue

Yes, everything is on the same network. This is my network topology: About my future plans to work around this issue: I bought myself a new router that can handle multiple networks. (Believe it or not, my current router can not do this ...) I want every interface to have its own network. I will set everything up next weekend. Let's see if this resolves the issue. Thank you very much for your assistance by the way! Very much appreciated! :) Have a great day!

Thanks for your reply! I attached my diagnostics zip file, that includes information about my interface configuration. unraid-server-diagnostics-20190221-0853.zip I assume the issue is related to a bug in unRAID or in the driver for the network cards.

I have a similar issue, probably related to the same bug in unRAID. Have a look at the following trace captured from my router: I have one management interface for unRAID itself (192.168.10.10) and 9 interfaces to be used by VMs (no IP addresses). However every time my router sends out an ARP request to find out the MAC address for the unRAID management interface, every interface responses. Only one of these responses has the right MAC address in it. So at the moment I can only reach my unRAID web GUI und network shares if I'm lucky ... I could not find out yet why this happens. Maybe someone else has any clues?

Hi there, I am having issues with my HP ProLiant DL380p Gen8 Server. For more details you can quickly scan over this thread here: Although I kind of solved the issue in the end by changing some tunables, at least so that parity checks work now, there are still issues persisting. For example: - High CPU usage (~25 % system) when working with PCIe lanes (Transferring data through the HBA, Downloading files through the Network card) - Very high CPU usage (>40 % in idle) when turning on VMs with many CPU cores passed through from different CPUs. My server basically works but I want to solve this issue. My old server (HP ProLiant DL180 G6) did not have this issue. I thought maybe someone here also has a ProLiant server and has / had the same issue? I will provide further details if needed.

Hi johnnie.black, I just figured it out! What I just did is I applied your Tunables from your previous post and started a Parity Check. The NMIs started immediately. Canceled the Partiy Check and started it again just to double check ... Yep ... disk speeds are bad and CPU usage is high right from the start of the Parity Check. Then I reset the Tunable values to default. Started the Parity Check again and ... it happened like before: At first everything looks normal (disk speeds as expected from 4 HDDs and CPU usage ~2 %) but after a few seconds the NMIs start. So I went like: Hmm... When I increase the Tunables it goes worse. What if I now decreased them? I thought taking the default values and halving them would be a good start: Tunable (nr_requests): 64 Tunable (md_num_stripes): 640 Tunable (md_sync_window): 192 Tunable (md_sync_thresh): 96 Wow! I did not think that this would work! Look at the system stats graphs: The only thing I need to figure out now is what these strange "spikes" are. The syslog shows no NMIs, no errors, nothing! Don't get me wrong, I'm really very glad that it is finally working! However these spikes are not normal. I think that it would help if I had some up-to-date information about Tunables what exactly they stand for and what they do. I'm sure that this was discussed already on the forum somewhere but I can't find it. Could you link a post where it is explained? That would be very great! Thank you very much!

@johnnie.black Do you think that this issue could be related to Tunables? I did not change them bacause I do not understand what they do and the wikipedia and forum posts are outdated (http://lime-technology.com/wiki/Improving_unRAID_Performance#User_Tunables and ). So mine are all set to default values. Are there Tunables that I could change to try and fix this issue? I am sorry if I am bothering you but I really want to fix this issue and I dont't know how I should get started and who else I could talk to.

When all of my VMs are running (mostly game servers) and a Prity Check is being started my system stats look like this: During the Parity Check all my gameservers have very bad performance drops. When I stop all VMs and start a Parity Check my graphs look like this: I have no clue what is going on here. unraid-server-diagnostics-20180727-0908.zip

When I put some real load on the server like starting many VMs simultaniously I see this in my syslog: Jul 26 21:09:36 unRAID-Server kernel: perf: interrupt took too long (4229 > 2500), lowering kernel.perf_event_max_sample_rate to 47000 Jul 26 21:09:37 unRAID-Server kernel: perf: interrupt took too long (6320 > 5286), lowering kernel.perf_event_max_sample_rate to 31000 Jul 26 21:09:46 unRAID-Server kernel: perf: interrupt took too long (8617 > 7900), lowering kernel.perf_event_max_sample_rate to 23000 Jul 26 21:09:51 unRAID-Server kernel: perf: interrupt took too long (12258 > 10771), lowering kernel.perf_event_max_sample_rate to 16000 Jul 26 21:09:56 unRAID-Server kernel: perf: interrupt took too long (16051 > 15322), lowering kernel.perf_event_max_sample_rate to 12000 Jul 26 21:10:08 unRAID-Server kernel: perf: interrupt took too long (21657 > 20063), lowering kernel.perf_event_max_sample_rate to 9000 Jul 26 21:10:25 unRAID-Server kernel: perf: interrupt took too long (27495 > 27071), lowering kernel.perf_event_max_sample_rate to 7000 Jul 26 21:11:06 unRAID-Server kernel: perf: interrupt took too long (35995 > 34368), lowering kernel.perf_event_max_sample_rate to 5000 Jul 26 21:12:45 unRAID-Server kernel: perf: interrupt took too long (46427 > 44993), lowering kernel.perf_event_max_sample_rate to 4000 Jul 26 21:15:29 unRAID-Server kernel: perf: interrupt took too long (58952 > 58033), lowering kernel.perf_event_max_sample_rate to 3000 Jul 26 21:19:25 unRAID-Server kernel: perf: interrupt took too long (76236 > 73690), lowering kernel.perf_event_max_sample_rate to 2000 Maybe that has got something to do with my NMIs?

Nope, there is nothing unusual there. What I did in the meantime: - BIOS Reset - Deactivated all unneccessary devices (on-board SATA Controller + on-board RAID-Controller) - Re-created the unRAID-USB-flash device But that didn't seem to help at all. An excerpt from my syslog during the parity check (started at 19:41:20): Jul 26 19:41:20 unRAID-Server emhttpd: req (2): startState=STARTED&file=&cmdCheck=Check&optionCorrect=correct&csrf_token=**************** Jul 26 19:41:20 unRAID-Server kernel: mdcmd (40): check correct Jul 26 19:41:20 unRAID-Server kernel: md: recovery thread: check P ... Jul 26 19:41:20 unRAID-Server kernel: md: using 1536k window, over a total of 1953514552 blocks. Jul 26 19:42:12 unRAID-Server sSMTP[5210]: Creating SSL connection to host Jul 26 19:42:12 unRAID-Server sSMTP[5210]: SSL connection using ECDHE-RSA-AES256-GCM-SHA384 Jul 26 19:42:14 unRAID-Server sSMTP[5210]: Sent mail for [email protected] (221 2.0.0 fwd26.t-online.de closing. / Closing.) uid=0 username=root outbytes=760 Jul 26 19:42:46 unRAID-Server kernel: INFO: rcu_sched self-detected stall on CPU Jul 26 19:42:46 unRAID-Server kernel: 21-...: (59999 ticks this GP) idle=1ee/140000000000001/0 softirq=1792/1792 fqs=13455 Jul 26 19:42:46 unRAID-Server kernel: (t=60001 jiffies g=6532 c=6531 q=24126) Jul 26 19:42:46 unRAID-Server kernel: NMI backtrace for cpu 21 Jul 26 19:42:46 unRAID-Server kernel: CPU: 21 PID: 3954 Comm: unraidd Not tainted 4.14.49-unRAID #1 Jul 26 19:42:46 unRAID-Server kernel: Hardware name: HP ProLiant DL380p Gen8, BIOS P70 05/21/2018 Jul 26 19:42:46 unRAID-Server kernel: Call Trace: Jul 26 19:42:46 unRAID-Server kernel: <IRQ> Jul 26 19:42:46 unRAID-Server kernel: dump_stack+0x5d/0x79 Jul 26 19:42:46 unRAID-Server kernel: INFO: rcu_sched detected stalls on CPUs/tasks: Jul 26 19:42:46 unRAID-Server kernel: nmi_cpu_backtrace+0x9b/0xba Jul 26 19:42:46 unRAID-Server kernel: ? irq_force_complete_move+0xf3/0xf3 Jul 26 19:42:46 unRAID-Server kernel: nmi_trigger_cpumask_backtrace+0x56/0xd4 Jul 26 19:42:46 unRAID-Server kernel: rcu_dump_cpu_stacks+0x8e/0xb8 Jul 26 19:42:46 unRAID-Server kernel: rcu_check_callbacks+0x212/0x5f0 Jul 26 19:42:46 unRAID-Server kernel: update_process_times+0x23/0x45 Jul 26 19:42:46 unRAID-Server kernel: tick_sched_timer+0x33/0x61 Jul 26 19:42:46 unRAID-Server kernel: __hrtimer_run_queues+0x78/0xc1 Jul 26 19:42:46 unRAID-Server kernel: hrtimer_interrupt+0x87/0x157 Jul 26 19:42:46 unRAID-Server kernel: smp_apic_timer_interrupt+0x75/0x85 Jul 26 19:42:46 unRAID-Server kernel: apic_timer_interrupt+0x7d/0x90 Jul 26 19:42:46 unRAID-Server kernel: </IRQ> Jul 26 19:42:46 unRAID-Server kernel: RIP: 0010:memcmp+0x2/0x1d Jul 26 19:42:46 unRAID-Server kernel: RSP: 0018:ffffc9000727bcd0 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff10 Jul 26 19:42:46 unRAID-Server kernel: RAX: 0000000000000000 RBX: ffff88080578bd20 RCX: 0000000000000409 Jul 26 19:42:46 unRAID-Server kernel: RDX: 0000000000000ff8 RSI: ffff8808057cc008 RDI: ffff8808057cc000 Jul 26 19:42:46 unRAID-Server kernel: RBP: 0000000000000258 R08: 0000000000000000 R09: ffff8808057cc000 Jul 26 19:42:46 unRAID-Server kernel: R10: ffff8808057cb000 R11: ffff8808057ca000 R12: ffff88081a045800 Jul 26 19:42:46 unRAID-Server kernel: R13: 0000000000000001 R14: 0000000000000003 R15: ffff8808057cc000 Jul 26 19:42:46 unRAID-Server kernel: check_parity+0x14f/0x30b [md_mod] Jul 26 19:42:46 unRAID-Server kernel: handle_stripe+0xefc/0x1293 [md_mod] Jul 26 19:42:46 unRAID-Server kernel: unraidd+0xb8/0x111 [md_mod] Jul 26 19:42:46 unRAID-Server kernel: ? md_open+0x2c/0x2c [md_mod] Jul 26 19:42:46 unRAID-Server kernel: ? md_thread+0xbc/0xcc [md_mod] Jul 26 19:42:46 unRAID-Server kernel: ? handle_stripe+0x1293/0x1293 [md_mod] Jul 26 19:42:46 unRAID-Server kernel: md_thread+0xbc/0xcc [md_mod] Jul 26 19:42:46 unRAID-Server kernel: ? wait_woken+0x68/0x68 Jul 26 19:42:46 unRAID-Server kernel: kthread+0x111/0x119 Jul 26 19:42:46 unRAID-Server kernel: ? kthread_create_on_node+0x3a/0x3a Jul 26 19:42:46 unRAID-Server kernel: ret_from_fork+0x35/0x40 Jul 26 19:42:46 unRAID-Server kernel: 21-...: (59999 ticks this GP) idle=1ee/140000000000001/0 softirq=1792/1792 fqs=13456 Jul 26 19:42:46 unRAID-Server kernel: (detected by 26, t=60005 jiffies, g=6532, c=6531, q=24126) Jul 26 19:42:46 unRAID-Server kernel: Sending NMI from CPU 26 to CPUs 21: Jul 26 19:42:46 unRAID-Server kernel: NMI backtrace for cpu 21 Jul 26 19:42:46 unRAID-Server kernel: CPU: 21 PID: 3954 Comm: unraidd Not tainted 4.14.49-unRAID #1 Jul 26 19:42:46 unRAID-Server kernel: Hardware name: HP ProLiant DL380p Gen8, BIOS P70 05/21/2018 Jul 26 19:42:46 unRAID-Server kernel: task: ffff88081ad53600 task.stack: ffffc90007278000 Jul 26 19:42:46 unRAID-Server kernel: RIP: 0010:memcmp+0x2/0x1d Jul 26 19:42:46 unRAID-Server kernel: RSP: 0018:ffffc9000727bcd0 EFLAGS: 00000246 Jul 26 19:42:46 unRAID-Server kernel: RAX: 0000000000000000 RBX: ffff88080578bd20 RCX: 0000000000000fba Jul 26 19:42:46 unRAID-Server kernel: RDX: 0000000000000ff8 RSI: ffff8808057cc008 RDI: ffff8808057cc000 Jul 26 19:42:46 unRAID-Server kernel: RBP: 0000000000000258 R08: 0000000000000000 R09: ffff8808057cc000 Jul 26 19:42:46 unRAID-Server kernel: R10: ffff8808057cb000 R11: ffff8808057ca000 R12: ffff88081a045800 Jul 26 19:42:46 unRAID-Server kernel: R13: 0000000000000001 R14: 0000000000000003 R15: ffff8808057cc000 Jul 26 19:42:46 unRAID-Server kernel: FS: 0000000000000000(0000) GS:ffff88081f8c0000(0000) knlGS:0000000000000000 Jul 26 19:42:46 unRAID-Server kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Jul 26 19:42:46 unRAID-Server kernel: CR2: 0000151a721d77a0 CR3: 0000000001c0a001 CR4: 00000000001606e0 Jul 26 19:42:46 unRAID-Server kernel: Call Trace: Jul 26 19:42:46 unRAID-Server kernel: check_parity+0x14f/0x30b [md_mod] Jul 26 19:42:46 unRAID-Server kernel: handle_stripe+0xefc/0x1293 [md_mod] Jul 26 19:42:46 unRAID-Server kernel: unraidd+0xb8/0x111 [md_mod] Jul 26 19:42:46 unRAID-Server kernel: ? md_open+0x2c/0x2c [md_mod] Jul 26 19:42:46 unRAID-Server kernel: ? md_thread+0xbc/0xcc [md_mod] Jul 26 19:42:46 unRAID-Server kernel: ? handle_stripe+0x1293/0x1293 [md_mod] Jul 26 19:42:46 unRAID-Server kernel: md_thread+0xbc/0xcc [md_mod] Jul 26 19:42:46 unRAID-Server kernel: ? wait_woken+0x68/0x68 Jul 26 19:42:46 unRAID-Server kernel: kthread+0x111/0x119 Jul 26 19:42:46 unRAID-Server kernel: ? kthread_create_on_node+0x3a/0x3a Jul 26 19:42:46 unRAID-Server kernel: ret_from_fork+0x35/0x40 Jul 26 19:42:46 unRAID-Server kernel: Code: 48 63 c1 4c 39 c0 73 19 49 8b 3c c1 48 85 ff 74 10 4c 89 d6 e8 71 ff ff ff 84 c0 75 09 ff c1 eb df b9 ea ff ff ff 89 c8 c3 31 c9 <48> 39 d1 74 13 0f b6 04 0f 44 0f b6 04 0e 48 ff c1 44 29 c0 74 Jul 26 19:43:14 unRAID-Server emhttpd: req (3): startState=STARTED&file=&csrf_token=****************&cmdNoCheck=Cancel Jul 26 19:43:14 unRAID-Server kernel: mdcmd (41): nocheck Jul 26 19:43:15 unRAID-Server kernel: md: md_do_sync: got signal, exit... Jul 26 19:43:15 unRAID-Server kernel: md: recovery thread: completion status: -4 Jul 26 19:44:01 unRAID-Server sSMTP[5754]: Creating SSL connection to host Jul 26 19:44:01 unRAID-Server sSMTP[5754]: SSL connection using ECDHE-RSA-AES256-GCM-SHA384 Jul 26 19:44:02 unRAID-Server sSMTP[5754]: Sent mail for [email protected] (221 2.0.0 fwd14.t-online.de closing. / Closing.) uid=0 username=root outbytes=78 Edit: I saw some "Advanced CPU Settings" in the BIOS but I did not touch them. Maybe some of these setting is causing those errors?

I can only find tow kinds of logs: - The "iLO Event Log" which shows me stuff like "Server reset." or "Power on request received by: Automatic Power Recovery.". - The "Integrated Management Log" which shows me stuff like "Firmware flashed (ProLiant System BIOS - P70 05/21/2018)" or "Maintenance note: Intelligent Provisioning was loaded." I can not find anything unusual related to NMIs there. Where would I find the system event log you mentioned earlier?

Yes, I did this with my HP H240 before. Same results. Yes, that's a good idea! I will give this a try now. Thank you for your participation and have a great day!

Hello again, my LSI SAS 9207-8i just arrived. I have installed it and it works perfectly. Except during Parity Checks... NMIs are still there. Even the plugin system.stats is outputting improssible values because of the "system overload". I dont't even know anymore what to do now. I'm very frustrated right now. unraid-server-diagnostics-20180726-1558.zip unraid-server-syslog-20180726-1558.zip