Got Call Traces!?


zeyoner

Recommended Posts

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.

iKVM_capture.jpg

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 by zeyoner
Link to comment

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.

Link to comment

 

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 by Squid
Link to comment
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!

Link to comment

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.

Link to comment
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.

Link to comment
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>

 

Link to comment
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.

Link to comment

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.