zeyoner Posted September 8, 2017 Share Posted September 8, 2017 (edited) Hi everyone, I'm experiencing an odd issue with my UnRaid 6.3.5 server. Due to the fact I do not have any idea on how to get it resolved. I'm reaching out and appreciate any assistance I receive. Now to what's going on. Today is the second day I ran into the same issue. It started yesterday. While I'm downloading via Crashplan docker and my daughter is watching Daniel Tiger from an SMB share. I lose connectivity to the server. No webgui no share access. I can still ping the server however. When I use iKVM (see attachment) It's as if there's an network issue. I tried reconnecting the cables and still same issue. The fact that I can still use iKVM to view the console proves networking is working because it's on the same NIC. I tried to login via the console. But it just sits there and does nothing after I enter the login. After a long wait it seems to reset itself. Then I am able to login again. I do not like this at all because it seems to be rebooting all of my server's services. dobby-diagnostics-20170908-1338.zip Can this be relayed to the plugin I have installed (Tips and Tricks) I have the CPU Scaling Governor to Performance. Edited September 8, 2017 by zeyoner Quote Link to comment
1812 Posted September 8, 2017 Share Posted September 8, 2017 you've got call traces! Sep 8 13:30:25 Dobby kernel: ---[ end trace 39f53c2f77d30f62 ]--- Sep 8 13:30:25 Dobby kernel: ------------[ cut here ]------------ Sep 8 13:30:25 Dobby kernel: WARNING: CPU: 5 PID: 11894 at fs/fuse/file.c:1600 fuse_write_file_get+0x5d/0x67 Sep 8 13:30:25 Dobby kernel: Modules linked in: xt_CHECKSUM iptable_mangle ipt_REJECT nf_reject_ipv4 ebtable_filter ebtables vhost_net tun vhost macvtap macvlan veth xt_nat ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_conntrack_ipv4 nf_nat_ipv4 iptable_filter ip_tables nf_nat md_mod bonding ixgbe mdio igb ptp pps_core fbcon ast bitblit fbcon_rotate fbcon_ccw fbcon_ud fbcon_cw ttm softcursor font drm_kms_helper cfbfillrect cfbimgblt cfbcopyarea drm mxm_wmi agpgart syscopyarea sysfillrect sysimgblt fb_sys_fops fb ahci i2c_i801 i2c_smbus libahci fbdev x86_pkg_temp_thermal coretemp i2c_algo_bit i2c_core kvm_intel nvme nvme_core kvm ipmi_si wmi [last unloaded: pps_core] Sep 8 13:30:25 Dobby kernel: CPU: 5 PID: 11894 Comm: rslsync Tainted: G B W 4.9.30-unRAID #1 Sep 8 13:30:25 Dobby kernel: Hardware name: Supermicro Super Server/X10SDV-TLN4F, BIOS 1.1c 10/03/2016 Sep 8 13:30:25 Dobby kernel: ffffc900097b79c8 ffffffff813a4a1b 0000000000000000 ffffffff81962c64 Sep 8 13:30:25 Dobby kernel: ffffc900097b7a08 ffffffff8104d0d9 000006400001b470 0000000000000000 Sep 8 13:30:25 Dobby kernel: ffff880799a88300 ffff880833157800 ffff880833157800 ffff88081cb60000 Sep 8 13:30:25 Dobby kernel: Call Trace: Sep 8 13:30:25 Dobby kernel: [<ffffffff813a4a1b>] dump_stack+0x61/0x7e Sep 8 13:30:25 Dobby kernel: [<ffffffff8104d0d9>] __warn+0xb8/0xd3 Sep 8 13:30:25 Dobby kernel: [<ffffffff8104d1a1>] warn_slowpath_null+0x18/0x1a Sep 8 13:30:25 Dobby kernel: [<ffffffff8124bbad>] fuse_write_file_get+0x5d/0x67 Sep 8 13:30:25 Dobby kernel: [<ffffffff8124deab>] fuse_writepage_locked+0x68/0x364 Sep 8 13:30:25 Dobby kernel: [<ffffffff8124e1ce>] fuse_launder_page+0x27/0x44 Sep 8 13:30:25 Dobby kernel: [<ffffffff810d3058>] invalidate_inode_pages2_range+0x246/0x36e Sep 8 13:30:25 Dobby kernel: [<ffffffff810d318f>] invalidate_inode_pages2+0xf/0x11 Sep 8 13:30:25 Dobby kernel: [<ffffffff8124bbf9>] fuse_finish_open+0x42/0xd4 Sep 8 13:30:25 Dobby kernel: [<ffffffff8124bd11>] fuse_open_common+0x86/0xad Sep 8 13:30:25 Dobby kernel: [<ffffffff8124bd38>] ? fuse_open_common+0xad/0xad Sep 8 13:30:25 Dobby kernel: [<ffffffff8124bd43>] fuse_open+0xb/0xd Sep 8 13:30:25 Dobby kernel: [<ffffffff8111fbaf>] do_dentry_open.isra.1+0x1b9/0x2a1 Sep 8 13:30:25 Dobby kernel: [<ffffffff81120735>] vfs_open+0x51/0x58 Sep 8 13:30:25 Dobby kernel: [<ffffffff8112e2e2>] path_openat+0xb14/0xca8 Sep 8 13:30:25 Dobby kernel: [<ffffffff8112cf15>] ? filename_lookup+0xba/0xd4 Sep 8 13:30:25 Dobby kernel: [<ffffffff8112e4be>] do_filp_open+0x48/0x9e Sep 8 13:30:25 Dobby kernel: [<ffffffff81120a71>] do_sys_open+0x137/0x1c6 Sep 8 13:30:25 Dobby kernel: [<ffffffff81120a71>] ? do_sys_open+0x137/0x1c6 Sep 8 13:30:25 Dobby kernel: [<ffffffff81120b19>] SyS_open+0x19/0x1b Sep 8 13:30:25 Dobby kernel: [<ffffffff8167f537>] entry_SYSCALL_64_fastpath+0x1a/0xa9 Sep 8 13:30:25 Dobby kernel: ---[ end trace 39f53c2f77d30f63 ]--- Sep 8 13:32:17 Dobby kernel: BUG: unable to handle kernel NULL pointer dereference at 0000000000000080 Sep 8 13:32:17 Dobby kernel: IP: [<ffffffff813c9567>] __percpu_counter_add+0x10/0x71 Sep 8 13:32:17 Dobby kernel: PGD 0 Sep 8 13:32:17 Dobby kernel: Sep 8 13:32:17 Dobby kernel: Oops: 0000 [#1] PREEMPT SMP Sep 8 13:32:17 Dobby kernel: Modules linked in: xt_CHECKSUM iptable_mangle ipt_REJECT nf_reject_ipv4 ebtable_filter ebtables vhost_net tun vhost macvtap macvlan veth xt_nat ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_conntrack_ipv4 nf_nat_ipv4 iptable_filter ip_tables nf_nat md_mod bonding ixgbe mdio igb ptp pps_core fbcon ast bitblit fbcon_rotate fbcon_ccw fbcon_ud fbcon_cw ttm softcursor font drm_kms_helper cfbfillrect cfbimgblt cfbcopyarea drm mxm_wmi agpgart syscopyarea sysfillrect sysimgblt fb_sys_fops fb ahci i2c_i801 i2c_smbus libahci fbdev x86_pkg_temp_thermal coretemp i2c_algo_bit i2c_core kvm_intel nvme nvme_core kvm ipmi_si wmi [last unloaded: pps_core] Sep 8 13:32:17 Dobby kernel: CPU: 4 PID: 1103 Comm: kswapd0 Tainted: G B W 4.9.30-unRAID #1 Sep 8 13:32:17 Dobby kernel: Hardware name: Supermicro Super Server/X10SDV-TLN4F, BIOS 1.1c 10/03/2016 Sep 8 13:32:17 Dobby kernel: task: ffff88085adfb300 task.stack: ffffc90003828000 Sep 8 13:32:17 Dobby kernel: RIP: 0010:[<ffffffff813c9567>] [<ffffffff813c9567>] __percpu_counter_add+0x10/0x71 Sep 8 13:32:17 Dobby kernel: RSP: 0018:ffffc9000382b9f0 EFLAGS: 00010082 Sep 8 13:32:17 Dobby kernel: RAX: 0000000000000004 RBX: 0000000000000246 RCX: 0000000000000000 Sep 8 13:32:17 Dobby kernel: RDX: 0000000000000028 RSI: ffffffffffffffff RDI: 0000000000000060 Sep 8 13:32:17 Dobby kernel: RBP: ffffc9000382ba08 R08: ffffffffffffffff R09: ffff88087fffa000 Sep 8 13:32:17 Dobby kernel: R10: 000000000001b4b8 R11: 000000000001b470 R12: ffff8808287dfb60 Sep 8 13:32:17 Dobby kernel: R13: 0000000000000000 R14: 0000000000000000 R15: ffffea0010d636e0 Sep 8 13:32:17 Dobby kernel: FS: 0000000000000000(0000) GS:ffff88085f300000(0000) knlGS:0000000000000000 Sep 8 13:32:17 Dobby kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Sep 8 13:32:17 Dobby kernel: CR2: 0000000000000080 CR3: 0000000001c09000 CR4: 00000000003406e0 Sep 8 13:32:17 Dobby kernel: Stack: Sep 8 13:32:17 Dobby kernel: 0000000000000246 ffff8808287dfb60 0000000000000000 ffffc9000382ba38 Sep 8 13:32:17 Dobby kernel: ffffffff810ce497 ffffea0010d636c0 ffff8808287dfcd0 ffff8808287dfcd0 Sep 8 13:32:17 Dobby kernel: ffffc9000382bc38 ffffc9000382bac0 ffffffff810d438d ffffc9000382bac0 Sep 8 13:32:17 Dobby kernel: Call Trace: Sep 8 13:32:17 Dobby kernel: [<ffffffff810ce497>] clear_page_dirty_for_io+0x130/0x183 Sep 8 13:32:17 Dobby kernel: [<ffffffff810d438d>] pageout.isra.7+0x107/0x210 Sep 8 13:32:17 Dobby kernel: [<ffffffff810f7bed>] ? page_referenced+0x73/0x153 Sep 8 13:32:17 Dobby kernel: [<ffffffff810f6955>] ? page_check_address_transhuge+0x306/0x306 Sep 8 13:32:17 Dobby kernel: [<ffffffff810f7a52>] ? page_get_anon_vma+0x84/0x84 Sep 8 13:32:17 Dobby kernel: [<ffffffff810d5f1b>] shrink_page_list+0x5a4/0x7f7 Sep 8 13:32:17 Dobby kernel: [<ffffffff810d6941>] shrink_inactive_list+0x2ee/0x40d Sep 8 13:32:17 Dobby kernel: [<ffffffff810d720d>] shrink_node_memcg+0x4b6/0x658 Sep 8 13:32:17 Dobby kernel: [<ffffffff810d746e>] shrink_node+0xbf/0x27a Sep 8 13:32:17 Dobby kernel: [<ffffffff810d746e>] ? shrink_node+0xbf/0x27a Sep 8 13:32:17 Dobby kernel: [<ffffffff810d813c>] kswapd+0x4a4/0x59e Sep 8 13:32:17 Dobby kernel: [<ffffffff810d7c98>] ? mem_cgroup_shrink_node+0x86/0x86 Sep 8 13:32:17 Dobby kernel: [<ffffffff81063939>] kthread+0xdb/0xe3 Sep 8 13:32:17 Dobby kernel: [<ffffffff8106385e>] ? kthread_park+0x52/0x52 Sep 8 13:32:17 Dobby kernel: [<ffffffff8167f785>] ret_from_fork+0x25/0x30 Sep 8 13:32:17 Dobby kernel: Code: 08 48 01 c3 eb c9 4c 89 e6 4c 89 ef e8 94 5b 2b 00 48 89 d8 5b 41 5c 41 5d 5d c3 55 48 89 e5 41 55 41 54 53 65 ff 05 29 3d c4 7e <48> 8b 47 20 48 63 ca 65 44 8b 20 4d 63 e4 49 01 f4 49 39 cc 7d Sep 8 13:32:17 Dobby kernel: RIP [<ffffffff813c9567>] __percpu_counter_add+0x10/0x71 Sep 8 13:32:17 Dobby kernel: RSP <ffffc9000382b9f0> Sep 8 13:32:17 Dobby kernel: CR2: 0000000000000080 Sep 8 13:32:17 Dobby kernel: ---[ end trace 39f53c2f77d30f64 ]--- Sep 8 13:32:17 Dobby kernel: note: kswapd0[1103] exited with preempt_count 1 Sep 8 13:32:23 Dobby kernel: TCP: request_sock_TCP: Possible SYN flooding on port 3389. Sending cookies. Check SNMP counters. Sep 8 13:33:42 Dobby kernel: BUG: Bad page state: 23315 messages suppressed Sep 8 13:33:42 Dobby kernel: BUG: Bad page state in process guacd pfn:12400 Sep 8 13:33:42 Dobby kernel: page:ffffea0000490000 count:0 mapcount:0 mapping: (null) index:0x1 Sep 8 13:33:42 Dobby kernel: flags: 0x100000000000014(referenced|dirty) Sep 8 13:33:42 Dobby kernel: page dumped because: PAGE_FLAGS_CHECK_AT_PREP flag set Sep 8 13:33:42 Dobby kernel: bad because of flags: 0x14(referenced|dirty) Sep 8 13:33:42 Dobby kernel: Modules linked in: xt_CHECKSUM iptable_mangle ipt_REJECT nf_reject_ipv4 ebtable_filter ebtables vhost_net tun vhost macvtap macvlan veth xt_nat ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_conntrack_ipv4 nf_nat_ipv4 iptable_filter ip_tables nf_nat md_mod bonding ixgbe mdio igb ptp pps_core fbcon ast bitblit fbcon_rotate fbcon_ccw fbcon_ud fbcon_cw ttm softcursor font drm_kms_helper cfbfillrect cfbimgblt cfbcopyarea drm mxm_wmi agpgart syscopyarea sysfillrect sysimgblt fb_sys_fops fb ahci i2c_i801 i2c_smbus libahci fbdev x86_pkg_temp_thermal coretemp i2c_algo_bit i2c_core kvm_intel nvme nvme_core kvm ipmi_si wmi [last unloaded: pps_core] Sep 8 13:33:42 Dobby kernel: CPU: 11 PID: 7592 Comm: guacd Tainted: G B D W 4.9.30-unRAID #1 Sep 8 13:33:42 Dobby kernel: Hardware name: Supermicro Super Server/X10SDV-TLN4F, BIOS 1.1c 10/03/2016 Sep 8 13:33:42 Dobby kernel: ffffc9000f573b08 ffffffff813a4a1b ffffea0000490000 0000000000000009 Sep 8 13:33:42 Dobby kernel: ffffc9000f573b30 ffffffff810c8b8d 0000000000000014 ffff88087fffa5c0 Sep 8 13:33:42 Dobby kernel: ffffea0000490000 ffffc9000f573b40 ffffffff810c8c93 ffffc9000f573bf8 Sep 8 13:33:42 Dobby kernel: Call Trace: Sep 8 13:33:42 Dobby kernel: [<ffffffff813a4a1b>] dump_stack+0x61/0x7e Sep 8 13:33:42 Dobby kernel: [<ffffffff810c8b8d>] bad_page+0xf3/0x10f Sep 8 13:33:42 Dobby kernel: [<ffffffff810c8c93>] check_new_page_bad+0x74/0x76 Sep 8 13:33:42 Dobby kernel: [<ffffffff810cb301>] get_page_from_freelist+0x771/0x78f Sep 8 13:33:42 Dobby kernel: [<ffffffff810cb74a>] __alloc_pages_nodemask+0x124/0xc71 Sep 8 13:33:42 Dobby kernel: [<ffffffff8111ce69>] ? memcg_kmem_charge+0x70/0xd2 Sep 8 13:33:42 Dobby kernel: [<ffffffff810cc26b>] ? __alloc_pages_nodemask+0xc45/0xc71 Sep 8 13:33:42 Dobby kernel: [<ffffffff810d1591>] ? release_pages+0xe6/0x2da Sep 8 13:33:42 Dobby kernel: [<ffffffff813b5f20>] ? find_next_bit+0x15/0x1b Sep 8 13:33:42 Dobby kernel: [<ffffffff81103969>] alloc_pages_vma+0x155/0x1f5 Sep 8 13:33:42 Dobby kernel: [<ffffffff8111343b>] do_huge_pmd_wp_page+0x21e/0xbea Sep 8 13:33:42 Dobby kernel: [<ffffffff81111139>] ? set_huge_zero_page+0x87/0x9c Sep 8 13:33:42 Dobby kernel: [<ffffffff810edbbd>] handle_mm_fault+0x319/0xf96 Sep 8 13:33:42 Dobby kernel: [<ffffffff81042252>] __do_page_fault+0x24a/0x3ed Sep 8 13:33:42 Dobby kernel: [<ffffffff81042438>] do_page_fault+0x22/0x27 Sep 8 13:33:42 Dobby kernel: [<ffffffff81680f18>] page_fault+0x28/0x30 Sep 8 13:35:40 Dobby login[31580]: invalid password for 'UNKNOWN' on '/dev/tty1' Sep 8 13:35:53 Dobby login[31580]: ROOT LOGIN on '/dev/tty1' I'm not good at reading these but they look very much network related. Recommend you update your post title with the words "Call Traces" and maybe someone who knows more will hop in. Quote Link to comment
zeyoner Posted September 8, 2017 Author Share Posted September 8, 2017 Thanks 1812, title updated. Quote Link to comment
Squid Posted September 9, 2017 Share Posted September 9, 2017 (edited) 2 hours ago, 1812 said: you've got call traces! That's an understatement! What you had was a bunch of page allocation stalls (computer brain farts while it tried to figure out how to allocate some memory for various processes). Then came a single Out Of Memory issued which killed off part of the KVM system. Then it all went downhill from there. A reboot will fix you up at least temporarily. How much memory have you allocated to your various VMs? Are you running preclears or any plugin particularly memory intensive? 2 hours ago, 1812 said: but they look very much network related. Not sure where you're seeing this (maybe I'm missing something), beyond the NIC seemingly having a heart attack at one point trying to figure out if its up or down and what speed that its running at. Edited September 9, 2017 by Squid Quote Link to comment
1812 Posted September 9, 2017 Share Posted September 9, 2017 2 minutes ago, Squid said: Not sure where you're seeing this (maybe I'm missing something), beyond the NIC seemingly having a heart attack at one point trying to figure out if its up or down and what speed that its running at. These are why I said that: [<ffffffff8104d1a1>] warn_slowpath_null+0x18/0x1a Sep 8 13:30:25 Dobby kernel: [<ffffffff8124bbad>] fuse_write_file_get+0x5d/0x67 Sep 8 13:30:25 Dobby kernel: [<ffffffff8124deab>] fuse_writepage_locked+0x68/0x364 Sep 8 13:30:25 Dobby kernel: [<ffffffff8124e1ce>] fuse_launder_page+0x27/0x44 TCP: request_sock_TCP: Possible SYN flooding on port 3389. Sending coo Modules linked in: xt_CHECKSUM iptable_mangle ipt_REJECT nf_reject_ipv4 ebtable But since i'm still learning to read/understand call traces, that's also why I said 2 hours ago, 1812 said: I'm not good at reading these.....maybe someone who knows more will hop in. and "someone" did! Quote Link to comment
Squid Posted September 9, 2017 Share Posted September 9, 2017 ok. Missed that. I gave up after looking at the first 100 traces.... I'm no expert, but syslog 101: Start at the top. To be quite honest, I checked out the diagnostics because I figured the answer was going to be easy due to the reference in the OP's snippet to fuse.c issuing the trace (I figured it was going to be drive filesystem corrupt). After the OOM and seeing hundreds of traces right after it, I think it may be safe to ignore everything at the end as you've got to look at the root cause. Quote Link to comment
1812 Posted September 9, 2017 Share Posted September 9, 2017 52 minutes ago, Squid said: ok. Missed that. I gave up after looking at the first 100 traces.... I'm no expert, but syslog 101: Start at the top. To be quite honest, I checked out the diagnostics because I figured the answer was going to be easy due to the reference in the OP's snippet to fuse.c issuing the trace (I figured it was going to be drive filesystem corrupt). After the OOM and seeing hundreds of traces right after it, I think it may be safe to ignore everything at the end as you've got to look at the root cause. Never give up. Never surrender! Thanks for the lesson. Quote Link to comment
zeyoner Posted September 9, 2017 Author Share Posted September 9, 2017 2 hours ago, Squid said: That's an understatement! What you had was a bunch of page allocation stalls (computer brain farts while it tried to figure out how to allocate some memory for various processes). Then came a single Out Of Memory issued which killed off part of the KVM system. Then it all went downhill from there. A reboot will fix you up at least temporarily. How much memory have you allocated to your various VMs? Are you running preclears or any plugin particularly memory intensive? Not sure where you're seeing this (maybe I'm missing something), beyond the NIC seemingly having a heart attack at one point trying to figure out if its up or down and what speed that its running at. At the time I was running Emby, Crashplan (restoring), streaming a video via SMB share, and my one VM. I do have preclear plugin installed but it wasn't clearing any disk. The VM is using 8GB and the server has 32GB. Memory usage is usually at 42%. 2 hours ago, Squid said: ok. Missed that. I gave up after looking at the first 100 traces.... I'm no expert, but syslog 101: Start at the top. To be quite honest, I checked out the diagnostics because I figured the answer was going to be easy due to the reference in the OP's snippet to fuse.c issuing the trace (I figured it was going to be drive filesystem corrupt). After the OOM and seeing hundreds of traces right after it, I think it may be safe to ignore everything at the end as you've got to look at the root cause. I'm out of my element I don't know what I should be doing. I've rebooted the server. Based on what I'm understanding the issue may lie within the VM? Here's the XML to the one VM I had running at the time. <domain type='kvm' id='2'> <name>Server 10</name> <uuid>2ce10c02-6c90-0a96-a1f8-725725e8d5c7</uuid> <metadata> <vmtemplate xmlns="unraid" name="Windows 10" icon="windows.png" os="windows10"/> </metadata> <memory unit='KiB'>8388608</memory> <currentMemory unit='KiB'>8388608</currentMemory> <memoryBacking> <nosharepages/> </memoryBacking> <vcpu placement='static'>8</vcpu> <cputune> <vcpupin vcpu='0' cpuset='4'/> <vcpupin vcpu='1' cpuset='5'/> <vcpupin vcpu='2' cpuset='6'/> <vcpupin vcpu='3' cpuset='7'/> <vcpupin vcpu='4' cpuset='12'/> <vcpupin vcpu='5' cpuset='13'/> <vcpupin vcpu='6' cpuset='14'/> <vcpupin vcpu='7' cpuset='15'/> </cputune> <resource> <partition>/machine</partition> </resource> <os> <type arch='x86_64' machine='pc-i440fx-2.7'>hvm</type> <loader readonly='yes' type='pflash'>/usr/share/qemu/ovmf-x64/OVMF_CODE-pure-efi.fd</loader> <nvram>/etc/libvirt/qemu/nvram/2ce10c02-6c90-0a96-a1f8-725725e8d5c7_VARS-pure-efi.fd</nvram> </os> <features> <acpi/> <apic/> <hyperv> <relaxed state='on'/> <vapic state='on'/> <spinlocks state='on' retries='8191'/> <vendor_id state='on' value='none'/> </hyperv> </features> <cpu mode='host-passthrough'> <topology sockets='1' cores='4' threads='2'/> </cpu> <clock offset='localtime'> <timer name='hypervclock' present='yes'/> <timer name='hpet' present='no'/> </clock> <on_poweroff>destroy</on_poweroff> <on_reboot>restart</on_reboot> <on_crash>restart</on_crash> <devices> <emulator>/usr/local/sbin/qemu</emulator> <disk type='file' device='disk'> <driver name='qemu' type='raw' cache='writeback'/> <source file='/mnt/user/domains/Server 10/vdisk1.img'/> <backingStore/> <target dev='hdc' bus='virtio'/> <boot order='1'/> <alias name='virtio-disk2'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> </disk> <disk type='file' device='cdrom'> <driver name='qemu' type='raw'/> <source file='/mnt/user/isos/Windows.iso'/> <backingStore/> <target dev='hda' bus='ide'/> <readonly/> <boot order='2'/> <alias name='ide0-0-0'/> <address type='drive' controller='0' bus='0' target='0' unit='0'/> </disk> <disk type='file' device='cdrom'> <driver name='qemu' type='raw'/> <source file='/mnt/user/isos/virtio-win-0.1.126-2.iso'/> <backingStore/> <target dev='hdb' bus='ide'/> <readonly/> <alias name='ide0-0-1'/> <address type='drive' controller='0' bus='0' target='0' unit='1'/> </disk> <controller type='usb' index='0' model='ich9-ehci1'> <alias name='usb'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x7'/> </controller> <controller type='usb' index='0' model='ich9-uhci1'> <alias name='usb'/> <master startport='0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0' multifunction='on'/> </controller> <controller type='usb' index='0' model='ich9-uhci2'> <alias name='usb'/> <master startport='2'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x1'/> </controller> <controller type='usb' index='0' model='ich9-uhci3'> <alias name='usb'/> <master startport='4'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x2'/> </controller> <controller type='pci' index='0' model='pci-root'> <alias name='pci.0'/> </controller> <controller type='ide' index='0'> <alias name='ide'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/> </controller> <controller type='virtio-serial' index='0'> <alias name='virtio-serial0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> </controller> <interface type='bridge'> <mac address='52:54:00:b6:0d:99'/> <source bridge='br0'/> <target dev='vnet0'/> <model type='virtio'/> <alias name='net0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface> <serial type='pty'> <source path='/dev/pts/0'/> <target port='0'/> <alias name='serial0'/> </serial> <console type='pty' tty='/dev/pts/0'> <source path='/dev/pts/0'/> <target type='serial' port='0'/> <alias name='serial0'/> </console> <channel type='unix'> <source mode='bind' path='/var/lib/libvirt/qemu/channel/target/domain-2-Server 10/org.qemu.guest_agent.0'/> <target type='virtio' name='org.qemu.guest_agent.0' state='connected'/> <alias name='channel0'/> <address type='virtio-serial' controller='0' bus='0' port='1'/> </channel> <input type='tablet' bus='usb'> <alias name='input0'/> <address type='usb' bus='0' port='1'/> </input> <input type='mouse' bus='ps2'> <alias name='input1'/> </input> <input type='keyboard' bus='ps2'> <alias name='input2'/> </input> <graphics type='vnc' port='5900' autoport='yes' websocket='5700' listen='0.0.0.0' keymap='en-us'> <listen type='address' address='0.0.0.0'/> </graphics> <video> <model type='qxl' ram='65536' vram='65536' vgamem='16384' heads='1' primary='yes'/> <alias name='video0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> </video> <memballoon model='virtio'> <alias name='balloon0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/> </memballoon> </devices> <seclabel type='none' model='none'/> <seclabel type='dynamic' model='dac' relabel='yes'> <label>+0:+100</label> <imagelabel>+0:+100</imagelabel> </seclabel> </domain> Quote Link to comment
Squid Posted September 9, 2017 Share Posted September 9, 2017 12 hours ago, zeyoner said: Crashplan (restoring) Crashplan is a pig memory wise. Perhaps limit its memory either within its settings somewhere or via the docker template. Quote Link to comment
zeyoner Posted September 9, 2017 Author Share Posted September 9, 2017 1 hour ago, Squid said: Crashplan is a pig memory wise. Perhaps limit its memory either within its settings somewhere or via the docker template. I've noticed it is a memory hog. I'm only restoring my backups so that I can move it away from Crashplan since they've done away with the consumer plan. Quote Link to comment
zeyoner Posted September 9, 2017 Author Share Posted September 9, 2017 So I finally decided to reboot the server and this is what I'm getting. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.