June 19, 201412 yr Hey everyone, I want to start collecting all feedback on issues related to Xen in Beta 6 right in this thread here. If you experience any issues in beta 6 that you weren't experiencing in 5a specifically when booted into Xen mode, please post them here. At the present moment, I believe a few users have reported the following problems (but these problems don't necessarily effect everyone): Xen Net VIF Crashing on certain VMs Issues occur attempting to convert from RAW to QCOW2 image format Issues occur when attempting to boot a Xen VM using a CFG file that was working with beta 5a Thanks Everyone!
June 19, 201412 yr Author Update: In testing, I was able to get a "once Xen" archVM to start up in KVM mode using virsh and a new domXML file. I am still having some challenges though in that I cannot console into the VM yet (virsh console doesn't work with the VM yet). Still working on this. I also have been able to repeatedly get libvirt to crash when trying to create a Xen VM with virsh under Xen boot mode. For now, folks should start Xen-based VMs using xl create or from the unRAID webGUI like they have been. Virsh/libvirt and Xen aren't playing together perfectly just yet...
June 20, 201412 yr probably should include issues still in b6 that were in b5a so that you can keep tracking them as valid b6 issues. and let the b5a threads die as they should. just my 2 cents.
June 20, 201412 yr Author probably should include issues still in b6 that were in b5a so that you can keep tracking them as valid b6 issues. and let the b5a threads die as they should. just my 2 cents. Probably a good idea. I have an "active issues" list in my notes right now for beta6 from what I've gathered thus far, but I don't have everything collected from 5a yet. We have some housekeeping to do for beta 7 I think, but we didn't have any major issues in our testing on multiple machines.
June 20, 201412 yr I would like to start off by saying you guys are doing a great job, I am a huge fan of unRAID. Keep up the good work. I have started playing with unRAID 6 Beta 6 and a XEN vm which worked just fine on 5a seems to be crashing. Also, if I try to shutdown the vm from the unRAID webGUI, it does not seem to work, I started it from the unRAID webGUI as well. Here is a partial syslog: Jun 19 22:32:23 Iron php: /usr/local/sbin/xenman start Tretflix Jun 19 22:32:41 Iron logger: /etc/xen/scripts/vif-bridge: online type_if=vif XENBUS_PATH=backend/vif/1/0 Jun 19 22:32:41 Iron kernel: device vif1.0 entered promiscuous mode Jun 19 22:32:41 Iron logger: /etc/xen/scripts/vif-bridge: Successful vif-bridge online for vif1.0, bridge br0. Jun 19 22:32:41 Iron logger: /etc/xen/scripts/vif-bridge: Writing backend/vif/1/0/hotplug-status connected to xenstore. Jun 19 22:32:41 Iron php: Parsing config from /mnt/cache/domains/Tretflix-v1.3_x86-NAS/Tretflix-v1.3_x86-NAS.cfg Jun 19 22:32:43 Iron kernel: br0: port 3(vif1.0) entered listening state Jun 19 22:32:43 Iron kernel: br0: port 3(vif1.0) entered listening state Jun 19 22:32:58 Iron kernel: br0: port 3(vif1.0) entered learning state Jun 19 22:33:13 Iron kernel: br0: topology change detected, sending tcn bpdu Jun 19 22:33:13 Iron kernel: br0: port 3(vif1.0) entered forwarding state Jun 19 22:35:44 Iron kernel: mdcmd (84): spindown 4 Jun 19 22:36:13 Iron kernel: ------------[ cut here ]------------ Jun 19 22:36:13 Iron kernel: kernel BUG at drivers/net/xen-netback/netback.c:629! Jun 19 22:36:13 Iron kernel: invalid opcode: 0000 [#1] SMP Jun 19 22:36:13 Iron kernel: Modules linked in: veth xt_nat ipt_MASQUERADE iptable_nat nf_conntrack_ipv4 nf_nat_ipv4 nf_nat md_mod iptable_filter ip_tables vhost_net vhost tun i2c_i801 ata_piix e1000e ptp pps_core sata_mv [last unloaded: md_mod] Jun 19 22:36:13 Iron kernel: CPU: 0 PID: 2975 Comm: vif1.0-guest-rx Not tainted 3.15.0-unRAID #4 Jun 19 22:36:13 Iron kernel: Hardware name: Supermicro X7SB4/E/X7SB4/E, BIOS 2.0a 08/12/2011 Jun 19 22:36:13 Iron kernel: task: ffff88020f7f0000 ti: ffff88017a0b8000 task.ti: ffff88017a0b8000 Jun 19 22:36:13 Iron kernel: RIP: e030:[] [] xenvif_rx_action+0x484/0x7ff Jun 19 22:36:13 Iron kernel: RSP: e02b:ffff88017a0bbda0 EFLAGS: 00010202 Jun 19 22:36:13 Iron kernel: RAX: 0000000000000013 RBX: 0000000000000012 RCX: ffffea00051c2480 Jun 19 22:36:13 Iron kernel: RDX: ffff88017a33b2c8 RSI: ffff880141b7fee0 RDI: 00000000000b2e70 Jun 19 22:36:13 Iron kernel: RBP: ffff88017a0bbe70 R08: 0000000000000000 R09: 0000000000000001 Jun 19 22:36:13 Iron kernel: R10: 0000160000000000 R11: ffff8801c7092000 R12: ffff880141b7fee0 Jun 19 22:36:13 Iron kernel: R13: 0000000000000011 R14: 0000000000000000 R15: ffff88017a330800 Jun 19 22:36:13 Iron kernel: FS: 00002b4a8fbe1700(0000) GS:ffff88021fc00000(0000) knlGS:0000000000000000 Jun 19 22:36:13 Iron kernel: CS: e033 DS: 0000 ES: 0000 CR0: 000000008005003b Jun 19 22:36:13 Iron kernel: CR2: 00002b4a8e48e000 CR3: 00000001ef08f000 CR4: 0000000000042660 Jun 19 22:36:13 Iron kernel: Stack: Jun 19 22:36:13 Iron kernel: ffff88017a0bbdf4 0000000000000000 ffff8802ffffffff ffff88020f7fe6e4 Jun 19 22:36:13 Iron kernel: ffff88017a0bbe08 000000117a0bbe40 ffff88017a33b148 00000001000a9007 Jun 19 22:36:13 Iron kernel: ffff88017a330800 0000000000000000 000000000f7f0200 ffff88017a0bbdf8 Jun 19 22:36:13 Iron kernel: Call Trace: Jun 19 22:36:13 Iron kernel: [] xenvif_kthread_guest_rx+0x108/0x1db Jun 19 22:36:13 Iron kernel: [] ? __wake_up_sync+0xd/0xd Jun 19 22:36:13 Iron kernel: [] ? xenvif_stop_queue+0x53/0x53 Jun 19 22:36:13 Iron kernel: [] kthread+0xd6/0xde Jun 19 22:36:13 Iron kernel: [] ? kthread_create_on_node+0x162/0x162 Jun 19 22:36:13 Iron kernel: [] ret_from_fork+0x7c/0xb0 Jun 19 22:36:13 Iron kernel: [] ? kthread_create_on_node+0x162/0x162 Jun 19 22:36:13 Iron kernel: Code: 8b 09 e8 25 f5 ff ff e9 0f ff ff ff 8b 45 b8 2b 85 6c ff ff ff 41 89 44 24 28 41 8b 87 34 a9 00 00 2b 85 68 ff ff ff 39 d8 76 02 <0f> 0b 48 8b 45 a0 48 8b 9d 50 ff ff ff 49 89 44 24 08 49 89 1c Jun 19 22:36:13 Iron kernel: RIP [] xenvif_rx_action+0x484/0x7ff Jun 19 22:36:13 Iron kernel: RSP Jun 19 22:36:13 Iron kernel: ---[ end trace de268a813dfdafc6 ]--- Please let me know if you need anything additional. Cheers
June 20, 201412 yr Author I have started playing with unRAID 6 Beta 6 and my XEN vm which worked just fine on 5a seems to be crashing. Also, if I try to shutdown from the GUI, it does not seem to work. Here is the syslog: Jun 19 22:32:23 Iron php: /usr/local/sbin/xenman start Tretflix Jun 19 22:32:41 Iron logger: /etc/xen/scripts/vif-bridge: online type_if=vif XENBUS_PATH=backend/vif/1/0 Jun 19 22:32:41 Iron kernel: device vif1.0 entered promiscuous mode Jun 19 22:32:41 Iron logger: /etc/xen/scripts/vif-bridge: Successful vif-bridge online for vif1.0, bridge br0. Jun 19 22:32:41 Iron logger: /etc/xen/scripts/vif-bridge: Writing backend/vif/1/0/hotplug-status connected to xenstore. Jun 19 22:32:41 Iron php: Parsing config from /mnt/cache/domains/Tretflix-v1.3_x86-NAS/Tretflix-v1.3_x86-NAS.cfg Jun 19 22:32:43 Iron kernel: br0: port 3(vif1.0) entered listening state Jun 19 22:32:43 Iron kernel: br0: port 3(vif1.0) entered listening state Jun 19 22:32:58 Iron kernel: br0: port 3(vif1.0) entered learning state Jun 19 22:33:13 Iron kernel: br0: topology change detected, sending tcn bpdu Jun 19 22:33:13 Iron kernel: br0: port 3(vif1.0) entered forwarding state Jun 19 22:35:44 Iron kernel: mdcmd (84): spindown 4 Jun 19 22:36:13 Iron kernel: ------------[ cut here ]------------ Jun 19 22:36:13 Iron kernel: kernel BUG at drivers/net/xen-netback/netback.c:629! Jun 19 22:36:13 Iron kernel: invalid opcode: 0000 [#1] SMP Jun 19 22:36:13 Iron kernel: Modules linked in: veth xt_nat ipt_MASQUERADE iptable_nat nf_conntrack_ipv4 nf_nat_ipv4 nf_nat md_mod iptable_filter ip_tables vhost_net vhost tun i2c_i801 ata_piix e1000e ptp pps_core sata_mv [last unloaded: md_mod] Jun 19 22:36:13 Iron kernel: CPU: 0 PID: 2975 Comm: vif1.0-guest-rx Not tainted 3.15.0-unRAID #4 Jun 19 22:36:13 Iron kernel: Hardware name: Supermicro X7SB4/E/X7SB4/E, BIOS 2.0a 08/12/2011 Jun 19 22:36:13 Iron kernel: task: ffff88020f7f0000 ti: ffff88017a0b8000 task.ti: ffff88017a0b8000 Jun 19 22:36:13 Iron kernel: RIP: e030:[] [] xenvif_rx_action+0x484/0x7ff Jun 19 22:36:13 Iron kernel: RSP: e02b:ffff88017a0bbda0 EFLAGS: 00010202 Jun 19 22:36:13 Iron kernel: RAX: 0000000000000013 RBX: 0000000000000012 RCX: ffffea00051c2480 Jun 19 22:36:13 Iron kernel: RDX: ffff88017a33b2c8 RSI: ffff880141b7fee0 RDI: 00000000000b2e70 Jun 19 22:36:13 Iron kernel: RBP: ffff88017a0bbe70 R08: 0000000000000000 R09: 0000000000000001 Jun 19 22:36:13 Iron kernel: R10: 0000160000000000 R11: ffff8801c7092000 R12: ffff880141b7fee0 Jun 19 22:36:13 Iron kernel: R13: 0000000000000011 R14: 0000000000000000 R15: ffff88017a330800 Jun 19 22:36:13 Iron kernel: FS: 00002b4a8fbe1700(0000) GS:ffff88021fc00000(0000) knlGS:0000000000000000 Jun 19 22:36:13 Iron kernel: CS: e033 DS: 0000 ES: 0000 CR0: 000000008005003b Jun 19 22:36:13 Iron kernel: CR2: 00002b4a8e48e000 CR3: 00000001ef08f000 CR4: 0000000000042660 Jun 19 22:36:13 Iron kernel: Stack: Jun 19 22:36:13 Iron kernel: ffff88017a0bbdf4 0000000000000000 ffff8802ffffffff ffff88020f7fe6e4 Jun 19 22:36:13 Iron kernel: ffff88017a0bbe08 000000117a0bbe40 ffff88017a33b148 00000001000a9007 Jun 19 22:36:13 Iron kernel: ffff88017a330800 0000000000000000 000000000f7f0200 ffff88017a0bbdf8 Jun 19 22:36:13 Iron kernel: Call Trace: Jun 19 22:36:13 Iron kernel: [] xenvif_kthread_guest_rx+0x108/0x1db Jun 19 22:36:13 Iron kernel: [] ? __wake_up_sync+0xd/0xd Jun 19 22:36:13 Iron kernel: [] ? xenvif_stop_queue+0x53/0x53 Jun 19 22:36:13 Iron kernel: [] kthread+0xd6/0xde Jun 19 22:36:13 Iron kernel: [] ? kthread_create_on_node+0x162/0x162 Jun 19 22:36:13 Iron kernel: [] ret_from_fork+0x7c/0xb0 Jun 19 22:36:13 Iron kernel: [] ? kthread_create_on_node+0x162/0x162 Jun 19 22:36:13 Iron kernel: Code: 8b 09 e8 25 f5 ff ff e9 0f ff ff ff 8b 45 b8 2b 85 6c ff ff ff 41 89 44 24 28 41 8b 87 34 a9 00 00 2b 85 68 ff ff ff 39 d8 76 02 <0f> 0b 48 8b 45 a0 48 8b 9d 50 ff ff ff 49 89 44 24 08 49 89 1c Jun 19 22:36:13 Iron kernel: RIP [] xenvif_rx_action+0x484/0x7ff Jun 19 22:36:13 Iron kernel: RSP Jun 19 22:36:13 Iron kernel: ---[ end trace de268a813dfdafc6 ]--- Any ideas? Can you share your /mnt/cache/domains/Tretflix-v1.3_x86-NAS/Tretflix-v1.3_x86-NAS.cfg file?
June 20, 201412 yr I have started playing with unRAID 6 Beta 6 and my XEN vm which worked just fine on 5a seems to be crashing. Also, if I try to shutdown from the GUI, it does not seem to work. Here is the syslog: Jun 19 22:32:23 Iron php: /usr/local/sbin/xenman start Tretflix Jun 19 22:32:41 Iron logger: /etc/xen/scripts/vif-bridge: online type_if=vif XENBUS_PATH=backend/vif/1/0 Jun 19 22:32:41 Iron kernel: device vif1.0 entered promiscuous mode Jun 19 22:32:41 Iron logger: /etc/xen/scripts/vif-bridge: Successful vif-bridge online for vif1.0, bridge br0. Jun 19 22:32:41 Iron logger: /etc/xen/scripts/vif-bridge: Writing backend/vif/1/0/hotplug-status connected to xenstore. Jun 19 22:32:41 Iron php: Parsing config from /mnt/cache/domains/Tretflix-v1.3_x86-NAS/Tretflix-v1.3_x86-NAS.cfg Jun 19 22:32:43 Iron kernel: br0: port 3(vif1.0) entered listening state Jun 19 22:32:43 Iron kernel: br0: port 3(vif1.0) entered listening state Jun 19 22:32:58 Iron kernel: br0: port 3(vif1.0) entered learning state Jun 19 22:33:13 Iron kernel: br0: topology change detected, sending tcn bpdu Jun 19 22:33:13 Iron kernel: br0: port 3(vif1.0) entered forwarding state Jun 19 22:35:44 Iron kernel: mdcmd (84): spindown 4 Jun 19 22:36:13 Iron kernel: ------------[ cut here ]------------ Jun 19 22:36:13 Iron kernel: kernel BUG at drivers/net/xen-netback/netback.c:629! Jun 19 22:36:13 Iron kernel: invalid opcode: 0000 [#1] SMP Jun 19 22:36:13 Iron kernel: Modules linked in: veth xt_nat ipt_MASQUERADE iptable_nat nf_conntrack_ipv4 nf_nat_ipv4 nf_nat md_mod iptable_filter ip_tables vhost_net vhost tun i2c_i801 ata_piix e1000e ptp pps_core sata_mv [last unloaded: md_mod] Jun 19 22:36:13 Iron kernel: CPU: 0 PID: 2975 Comm: vif1.0-guest-rx Not tainted 3.15.0-unRAID #4 Jun 19 22:36:13 Iron kernel: Hardware name: Supermicro X7SB4/E/X7SB4/E, BIOS 2.0a 08/12/2011 Jun 19 22:36:13 Iron kernel: task: ffff88020f7f0000 ti: ffff88017a0b8000 task.ti: ffff88017a0b8000 Jun 19 22:36:13 Iron kernel: RIP: e030:[] [] xenvif_rx_action+0x484/0x7ff Jun 19 22:36:13 Iron kernel: RSP: e02b:ffff88017a0bbda0 EFLAGS: 00010202 Jun 19 22:36:13 Iron kernel: RAX: 0000000000000013 RBX: 0000000000000012 RCX: ffffea00051c2480 Jun 19 22:36:13 Iron kernel: RDX: ffff88017a33b2c8 RSI: ffff880141b7fee0 RDI: 00000000000b2e70 Jun 19 22:36:13 Iron kernel: RBP: ffff88017a0bbe70 R08: 0000000000000000 R09: 0000000000000001 Jun 19 22:36:13 Iron kernel: R10: 0000160000000000 R11: ffff8801c7092000 R12: ffff880141b7fee0 Jun 19 22:36:13 Iron kernel: R13: 0000000000000011 R14: 0000000000000000 R15: ffff88017a330800 Jun 19 22:36:13 Iron kernel: FS: 00002b4a8fbe1700(0000) GS:ffff88021fc00000(0000) knlGS:0000000000000000 Jun 19 22:36:13 Iron kernel: CS: e033 DS: 0000 ES: 0000 CR0: 000000008005003b Jun 19 22:36:13 Iron kernel: CR2: 00002b4a8e48e000 CR3: 00000001ef08f000 CR4: 0000000000042660 Jun 19 22:36:13 Iron kernel: Stack: Jun 19 22:36:13 Iron kernel: ffff88017a0bbdf4 0000000000000000 ffff8802ffffffff ffff88020f7fe6e4 Jun 19 22:36:13 Iron kernel: ffff88017a0bbe08 000000117a0bbe40 ffff88017a33b148 00000001000a9007 Jun 19 22:36:13 Iron kernel: ffff88017a330800 0000000000000000 000000000f7f0200 ffff88017a0bbdf8 Jun 19 22:36:13 Iron kernel: Call Trace: Jun 19 22:36:13 Iron kernel: [] xenvif_kthread_guest_rx+0x108/0x1db Jun 19 22:36:13 Iron kernel: [] ? __wake_up_sync+0xd/0xd Jun 19 22:36:13 Iron kernel: [] ? xenvif_stop_queue+0x53/0x53 Jun 19 22:36:13 Iron kernel: [] kthread+0xd6/0xde Jun 19 22:36:13 Iron kernel: [] ? kthread_create_on_node+0x162/0x162 Jun 19 22:36:13 Iron kernel: [] ret_from_fork+0x7c/0xb0 Jun 19 22:36:13 Iron kernel: [] ? kthread_create_on_node+0x162/0x162 Jun 19 22:36:13 Iron kernel: Code: 8b 09 e8 25 f5 ff ff e9 0f ff ff ff 8b 45 b8 2b 85 6c ff ff ff 41 89 44 24 28 41 8b 87 34 a9 00 00 2b 85 68 ff ff ff 39 d8 76 02 <0f> 0b 48 8b 45 a0 48 8b 9d 50 ff ff ff 49 89 44 24 08 49 89 1c Jun 19 22:36:13 Iron kernel: RIP [] xenvif_rx_action+0x484/0x7ff Jun 19 22:36:13 Iron kernel: RSP Jun 19 22:36:13 Iron kernel: ---[ end trace de268a813dfdafc6 ]--- Any ideas? Can you share your /mnt/cache/domains/Tretflix-v1.3_x86-NAS/Tretflix-v1.3_x86-NAS.cfg file? Sure Thing: name = "Tretflix" bootloader = "pygrub" memory = 3072 vcpus = 2 disk = [ 'phy:/mnt/cache/domains/Tretflix-v1.3_x86-NAS/Tretflix-v1.3_x86-NAS-disk1.raw,xvda,w', ] vif = [ 'mac=00:16:3e:01:01:02,bridge=br0' ] bootloader = "pygrub"
June 20, 201412 yr Author I have started playing with unRAID 6 Beta 6 and my XEN vm which worked just fine on 5a seems to be crashing. Also, if I try to shutdown from the GUI, it does not seem to work. Here is the syslog: Jun 19 22:32:23 Iron php: /usr/local/sbin/xenman start Tretflix Jun 19 22:32:41 Iron logger: /etc/xen/scripts/vif-bridge: online type_if=vif XENBUS_PATH=backend/vif/1/0 Jun 19 22:32:41 Iron kernel: device vif1.0 entered promiscuous mode Jun 19 22:32:41 Iron logger: /etc/xen/scripts/vif-bridge: Successful vif-bridge online for vif1.0, bridge br0. Jun 19 22:32:41 Iron logger: /etc/xen/scripts/vif-bridge: Writing backend/vif/1/0/hotplug-status connected to xenstore. Jun 19 22:32:41 Iron php: Parsing config from /mnt/cache/domains/Tretflix-v1.3_x86-NAS/Tretflix-v1.3_x86-NAS.cfg Jun 19 22:32:43 Iron kernel: br0: port 3(vif1.0) entered listening state Jun 19 22:32:43 Iron kernel: br0: port 3(vif1.0) entered listening state Jun 19 22:32:58 Iron kernel: br0: port 3(vif1.0) entered learning state Jun 19 22:33:13 Iron kernel: br0: topology change detected, sending tcn bpdu Jun 19 22:33:13 Iron kernel: br0: port 3(vif1.0) entered forwarding state Jun 19 22:35:44 Iron kernel: mdcmd (84): spindown 4 Jun 19 22:36:13 Iron kernel: ------------[ cut here ]------------ Jun 19 22:36:13 Iron kernel: kernel BUG at drivers/net/xen-netback/netback.c:629! Jun 19 22:36:13 Iron kernel: invalid opcode: 0000 [#1] SMP Jun 19 22:36:13 Iron kernel: Modules linked in: veth xt_nat ipt_MASQUERADE iptable_nat nf_conntrack_ipv4 nf_nat_ipv4 nf_nat md_mod iptable_filter ip_tables vhost_net vhost tun i2c_i801 ata_piix e1000e ptp pps_core sata_mv [last unloaded: md_mod] Jun 19 22:36:13 Iron kernel: CPU: 0 PID: 2975 Comm: vif1.0-guest-rx Not tainted 3.15.0-unRAID #4 Jun 19 22:36:13 Iron kernel: Hardware name: Supermicro X7SB4/E/X7SB4/E, BIOS 2.0a 08/12/2011 Jun 19 22:36:13 Iron kernel: task: ffff88020f7f0000 ti: ffff88017a0b8000 task.ti: ffff88017a0b8000 Jun 19 22:36:13 Iron kernel: RIP: e030:[] [] xenvif_rx_action+0x484/0x7ff Jun 19 22:36:13 Iron kernel: RSP: e02b:ffff88017a0bbda0 EFLAGS: 00010202 Jun 19 22:36:13 Iron kernel: RAX: 0000000000000013 RBX: 0000000000000012 RCX: ffffea00051c2480 Jun 19 22:36:13 Iron kernel: RDX: ffff88017a33b2c8 RSI: ffff880141b7fee0 RDI: 00000000000b2e70 Jun 19 22:36:13 Iron kernel: RBP: ffff88017a0bbe70 R08: 0000000000000000 R09: 0000000000000001 Jun 19 22:36:13 Iron kernel: R10: 0000160000000000 R11: ffff8801c7092000 R12: ffff880141b7fee0 Jun 19 22:36:13 Iron kernel: R13: 0000000000000011 R14: 0000000000000000 R15: ffff88017a330800 Jun 19 22:36:13 Iron kernel: FS: 00002b4a8fbe1700(0000) GS:ffff88021fc00000(0000) knlGS:0000000000000000 Jun 19 22:36:13 Iron kernel: CS: e033 DS: 0000 ES: 0000 CR0: 000000008005003b Jun 19 22:36:13 Iron kernel: CR2: 00002b4a8e48e000 CR3: 00000001ef08f000 CR4: 0000000000042660 Jun 19 22:36:13 Iron kernel: Stack: Jun 19 22:36:13 Iron kernel: ffff88017a0bbdf4 0000000000000000 ffff8802ffffffff ffff88020f7fe6e4 Jun 19 22:36:13 Iron kernel: ffff88017a0bbe08 000000117a0bbe40 ffff88017a33b148 00000001000a9007 Jun 19 22:36:13 Iron kernel: ffff88017a330800 0000000000000000 000000000f7f0200 ffff88017a0bbdf8 Jun 19 22:36:13 Iron kernel: Call Trace: Jun 19 22:36:13 Iron kernel: [] xenvif_kthread_guest_rx+0x108/0x1db Jun 19 22:36:13 Iron kernel: [] ? __wake_up_sync+0xd/0xd Jun 19 22:36:13 Iron kernel: [] ? xenvif_stop_queue+0x53/0x53 Jun 19 22:36:13 Iron kernel: [] kthread+0xd6/0xde Jun 19 22:36:13 Iron kernel: [] ? kthread_create_on_node+0x162/0x162 Jun 19 22:36:13 Iron kernel: [] ret_from_fork+0x7c/0xb0 Jun 19 22:36:13 Iron kernel: [] ? kthread_create_on_node+0x162/0x162 Jun 19 22:36:13 Iron kernel: Code: 8b 09 e8 25 f5 ff ff e9 0f ff ff ff 8b 45 b8 2b 85 6c ff ff ff 41 89 44 24 28 41 8b 87 34 a9 00 00 2b 85 68 ff ff ff 39 d8 76 02 <0f> 0b 48 8b 45 a0 48 8b 9d 50 ff ff ff 49 89 44 24 08 49 89 1c Jun 19 22:36:13 Iron kernel: RIP [] xenvif_rx_action+0x484/0x7ff Jun 19 22:36:13 Iron kernel: RSP Jun 19 22:36:13 Iron kernel: ---[ end trace de268a813dfdafc6 ]--- Any ideas? Can you share your /mnt/cache/domains/Tretflix-v1.3_x86-NAS/Tretflix-v1.3_x86-NAS.cfg file? Sure Thing: name = "Tretflix" bootloader = "pygrub" memory = 3072 vcpus = 2 disk = [ 'phy:/mnt/cache/domains/Tretflix-v1.3_x86-NAS/Tretflix-v1.3_x86-NAS-disk1.raw,xvda,w', ] vif = [ 'mac=00:16:3e:01:01:02,bridge=br0' ] bootloader = "pygrub" Ok, this is a weird issue with Xen that we had with a previous kernel version with some "desktop-grade" machines but those issues were resolved in 3.15. Never had those issues on our SuperMicro test server. Trying to pin down the root cause of this but there may be another way around this. This is an intermittent issue that a few others have reported as well. If your VM is a production system, please revert to 5a or wait until a guide for converting to KVM is posted. These network issues have not been seen on KVM at all...
June 20, 201412 yr Ok, this is a weird issue with Xen that we had with a previous kernel version with some "desktop-grade" machines but those issues were resolved in 3.15. Never had those issues on our SuperMicro test server. Trying to pin down the root cause of this but there may be another way around this. This is an intermittent issue that a few others have reported as well. If your VM is a production system, please revert to 5a or wait until a guide for converting to KVM is posted. These network issues have not been seen on KVM at all... Thanks for the quick response, I plan to use docker anyway for the task that this vm was running. I only wanted to get some of my settings from the XEN vm in order to configure and test (in docker). If needed, I will revert to 5a to get what I need from the vm, and revert back to 6 to play with docker. But I wanted to share as you were asking for any issues in XEN from 5a to 6.
June 20, 201412 yr Author Ok, this is a weird issue with Xen that we had with a previous kernel version with some "desktop-grade" machines but those issues were resolved in 3.15. Never had those issues on our SuperMicro test server. Trying to pin down the root cause of this but there may be another way around this. This is an intermittent issue that a few others have reported as well. If your VM is a production system, please revert to 5a or wait until a guide for converting to KVM is posted. These network issues have not been seen on KVM at all... Thanks for the quick response, I plan to use docker anyway for the task that this vm was running. I only wanted to get some of my settings from the XEN vm in order to configure and test (in docker). If needed, I will revert to 5a to get what I need from the vm, and revert back to 6 to play with docker. But I wanted to share as you were asking for any issues in XEN from 5a to 6. there may be a way to mount the vDisk as a device to UnRaid and then extract your data that way... Sent from my Nexus 5 using Tapatalk
June 20, 201412 yr I have started playing with unRAID 6 Beta 6 and my XEN vm which worked just fine on 5a seems to be crashing. Also, if I try to shutdown from the GUI, it does not seem to work. Here is the syslog: Jun 19 22:32:23 Iron php: /usr/local/sbin/xenman start Tretflix Jun 19 22:32:41 Iron logger: /etc/xen/scripts/vif-bridge: online type_if=vif XENBUS_PATH=backend/vif/1/0 Jun 19 22:32:41 Iron kernel: device vif1.0 entered promiscuous mode Jun 19 22:32:41 Iron logger: /etc/xen/scripts/vif-bridge: Successful vif-bridge online for vif1.0, bridge br0. Jun 19 22:32:41 Iron logger: /etc/xen/scripts/vif-bridge: Writing backend/vif/1/0/hotplug-status connected to xenstore. Jun 19 22:32:41 Iron php: Parsing config from /mnt/cache/domains/Tretflix-v1.3_x86-NAS/Tretflix-v1.3_x86-NAS.cfg Jun 19 22:32:43 Iron kernel: br0: port 3(vif1.0) entered listening state Jun 19 22:32:43 Iron kernel: br0: port 3(vif1.0) entered listening state Jun 19 22:32:58 Iron kernel: br0: port 3(vif1.0) entered learning state Jun 19 22:33:13 Iron kernel: br0: topology change detected, sending tcn bpdu Jun 19 22:33:13 Iron kernel: br0: port 3(vif1.0) entered forwarding state Jun 19 22:35:44 Iron kernel: mdcmd (84): spindown 4 Jun 19 22:36:13 Iron kernel: ------------[ cut here ]------------ Jun 19 22:36:13 Iron kernel: kernel BUG at drivers/net/xen-netback/netback.c:629! Jun 19 22:36:13 Iron kernel: invalid opcode: 0000 [#1] SMP Jun 19 22:36:13 Iron kernel: Modules linked in: veth xt_nat ipt_MASQUERADE iptable_nat nf_conntrack_ipv4 nf_nat_ipv4 nf_nat md_mod iptable_filter ip_tables vhost_net vhost tun i2c_i801 ata_piix e1000e ptp pps_core sata_mv [last unloaded: md_mod] Jun 19 22:36:13 Iron kernel: CPU: 0 PID: 2975 Comm: vif1.0-guest-rx Not tainted 3.15.0-unRAID #4 Jun 19 22:36:13 Iron kernel: Hardware name: Supermicro X7SB4/E/X7SB4/E, BIOS 2.0a 08/12/2011 Jun 19 22:36:13 Iron kernel: task: ffff88020f7f0000 ti: ffff88017a0b8000 task.ti: ffff88017a0b8000 Jun 19 22:36:13 Iron kernel: RIP: e030:[] [] xenvif_rx_action+0x484/0x7ff Jun 19 22:36:13 Iron kernel: RSP: e02b:ffff88017a0bbda0 EFLAGS: 00010202 Jun 19 22:36:13 Iron kernel: RAX: 0000000000000013 RBX: 0000000000000012 RCX: ffffea00051c2480 Jun 19 22:36:13 Iron kernel: RDX: ffff88017a33b2c8 RSI: ffff880141b7fee0 RDI: 00000000000b2e70 Jun 19 22:36:13 Iron kernel: RBP: ffff88017a0bbe70 R08: 0000000000000000 R09: 0000000000000001 Jun 19 22:36:13 Iron kernel: R10: 0000160000000000 R11: ffff8801c7092000 R12: ffff880141b7fee0 Jun 19 22:36:13 Iron kernel: R13: 0000000000000011 R14: 0000000000000000 R15: ffff88017a330800 Jun 19 22:36:13 Iron kernel: FS: 00002b4a8fbe1700(0000) GS:ffff88021fc00000(0000) knlGS:0000000000000000 Jun 19 22:36:13 Iron kernel: CS: e033 DS: 0000 ES: 0000 CR0: 000000008005003b Jun 19 22:36:13 Iron kernel: CR2: 00002b4a8e48e000 CR3: 00000001ef08f000 CR4: 0000000000042660 Jun 19 22:36:13 Iron kernel: Stack: Jun 19 22:36:13 Iron kernel: ffff88017a0bbdf4 0000000000000000 ffff8802ffffffff ffff88020f7fe6e4 Jun 19 22:36:13 Iron kernel: ffff88017a0bbe08 000000117a0bbe40 ffff88017a33b148 00000001000a9007 Jun 19 22:36:13 Iron kernel: ffff88017a330800 0000000000000000 000000000f7f0200 ffff88017a0bbdf8 Jun 19 22:36:13 Iron kernel: Call Trace: Jun 19 22:36:13 Iron kernel: [] xenvif_kthread_guest_rx+0x108/0x1db Jun 19 22:36:13 Iron kernel: [] ? __wake_up_sync+0xd/0xd Jun 19 22:36:13 Iron kernel: [] ? xenvif_stop_queue+0x53/0x53 Jun 19 22:36:13 Iron kernel: [] kthread+0xd6/0xde Jun 19 22:36:13 Iron kernel: [] ? kthread_create_on_node+0x162/0x162 Jun 19 22:36:13 Iron kernel: [] ret_from_fork+0x7c/0xb0 Jun 19 22:36:13 Iron kernel: [] ? kthread_create_on_node+0x162/0x162 Jun 19 22:36:13 Iron kernel: Code: 8b 09 e8 25 f5 ff ff e9 0f ff ff ff 8b 45 b8 2b 85 6c ff ff ff 41 89 44 24 28 41 8b 87 34 a9 00 00 2b 85 68 ff ff ff 39 d8 76 02 <0f> 0b 48 8b 45 a0 48 8b 9d 50 ff ff ff 49 89 44 24 08 49 89 1c Jun 19 22:36:13 Iron kernel: RIP [] xenvif_rx_action+0x484/0x7ff Jun 19 22:36:13 Iron kernel: RSP Jun 19 22:36:13 Iron kernel: ---[ end trace de268a813dfdafc6 ]--- Any ideas? Can you share your /mnt/cache/domains/Tretflix-v1.3_x86-NAS/Tretflix-v1.3_x86-NAS.cfg file? Sure Thing: name = "Tretflix" bootloader = "pygrub" memory = 3072 vcpus = 2 disk = [ 'phy:/mnt/cache/domains/Tretflix-v1.3_x86-NAS/Tretflix-v1.3_x86-NAS-disk1.raw,xvda,w', ] vif = [ 'mac=00:16:3e:01:01:02,bridge=br0' ] bootloader = "pygrub" Ok, this is a weird issue with Xen that we had with a previous kernel version with some "desktop-grade" machines but those issues were resolved in 3.15. Never had those issues on our SuperMicro test server. Trying to pin down the root cause of this but there may be another way around this. This is an intermittent issue that a few others have reported as well. If your VM is a production system, please revert to 5a or wait until a guide for converting to KVM is posted. These network issues have not been seen on KVM at all... I have the exact same issue but only my Windows VM crashes about 5 minutes. My lubuntu VM run fine.
June 20, 201412 yr I'm relatively new to the Unraid community, but I was curios, does it matter that he has two bootloaders in his config file even though they are the same? Seems redundant, unnecessary, and could possibly cause an error?
June 20, 201412 yr Just got this crash a couple of min ago on my xen - latest beta Jun 20 00:56:33 Tower kernel: ------------[ cut here ]------------ Jun 20 00:56:33 Tower kernel: kernel BUG at drivers/net/xen-netback/netback.c:629! Jun 20 00:56:33 Tower kernel: invalid opcode: 0000 [#1] SMP Jun 20 00:56:33 Tower kernel: Modules linked in: ipt_MASQUERADE iptable_nat nf_conntrack_ipv4 nf_nat_ipv4 nf_nat nct6775 coretemp w83627ehf hwmon_vid md_mod iptable_filter ip_tables vhost_net vhost tun e1000e ahci i2c_i801 mvsas ptp libahci libsas pps_core scsi_transport_sas ipmi_si Jun 20 00:56:33 Tower kernel: CPU: 0 PID: 4001 Comm: vif1.0-guest-rx Not tainted 3.15.0-unRAID #4 Jun 20 00:56:33 Tower kernel: Hardware name: Supermicro X9SCL/X9SCM/X9SCL/X9SCM, BIOS 2.0b 09/17/2012 Jun 20 00:56:33 Tower kernel: task: ffff88006f2e2e80 ti: ffff880014570000 task.ti: ffff880014570000 Jun 20 00:56:33 Tower kernel: RIP: e030:[<ffffffff81404fba>] [<ffffffff81404fba>] xenvif_rx_action+0x484/0x7ff Jun 20 00:56:33 Tower kernel: RSP: e02b:ffff880014573da0 EFLAGS: 00010202 Jun 20 00:56:33 Tower kernel: RAX: 0000000000000013 RBX: 0000000000000012 RCX: ffffea0000c7e600 Jun 20 00:56:33 Tower kernel: RDX: ffff88001469b2b8 RSI: ffff880000ae30e0 RDI: 00000000001783d1 Jun 20 00:56:33 Tower kernel: RBP: ffff880014573e70 R08: 0000000000000000 R09: 0000000000000001 Jun 20 00:56:33 Tower kernel: R10: 0000160000000000 R11: ffff8800b1f98000 R12: ffff880000ae30e0 Jun 20 00:56:33 Tower kernel: R13: 0000000000000011 R14: 0000000000001000 R15: ffff880014690800 Jun 20 00:56:33 Tower kernel: FS: 00002b44230dbe40(0000) GS:ffff88007ee00000(0000) knlGS:0000000000000000 Jun 20 00:56:33 Tower kernel: CS: e033 DS: 0000 ES: 0000 CR0: 0000000080050033 Jun 20 00:56:33 Tower kernel: CR2: 00002abf5ce00000 CR3: 000000006b608000 CR4: 0000000000042660 Jun 20 00:56:33 Tower kernel: Stack: Jun 20 00:56:33 Tower kernel: ffff880014573df4 0000000000000000 00000000ffffffff ffff88007ee0b0b0 Jun 20 00:56:33 Tower kernel: ffff880014573e08 000000116f2e0280 ffff88001469b148 00000000004c6586 Jun 20 00:56:33 Tower kernel: ffff880014690800 0000000000001000 0000000000000000 ffff880014573df8 Jun 20 00:56:33 Tower kernel: Call Trace: Jun 20 00:56:33 Tower kernel: [<ffffffff814068ab>] xenvif_kthread_guest_rx+0x108/0x1db Jun 20 00:56:33 Tower kernel: [<ffffffff8106e362>] ? __wake_up_sync+0xd/0xd Jun 20 00:56:33 Tower kernel: [<ffffffff814067a3>] ? xenvif_stop_queue+0x53/0x53 Jun 20 00:56:33 Tower kernel: [<ffffffff81057fbb>] kthread+0xd6/0xde Jun 20 00:56:33 Tower kernel: [<ffffffff81057ee5>] ? kthread_create_on_node+0x162/0x162 Jun 20 00:56:33 Tower kernel: [<ffffffff8157e94c>] ret_from_fork+0x7c/0xb0 Jun 20 00:56:33 Tower kernel: [<ffffffff81057ee5>] ? kthread_create_on_node+0x162/0x162 Jun 20 00:56:33 Tower kernel: Code: 8b 09 e8 25 f5 ff ff e9 0f ff ff ff 8b 45 b8 2b 85 6c ff ff ff 41 89 44 24 28 41 8b 87 34 a9 00 00 2b 85 68 ff ff ff 39 d8 76 02 <0f> 0b 48 8b 45 a0 48 8b 9d 50 ff ff ff 49 89 44 24 08 49 89 1c Jun 20 00:56:33 Tower kernel: RIP [<ffffffff81404fba>] xenvif_rx_action+0x484/0x7ff Jun 20 00:56:33 Tower kernel: RSP <ffff880014573da0> Jun 20 00:56:33 Tower kernel: ---[ end trace c637dfa9a55d6581 ]--- ArchVM is locked solid Tried to destroy it and now have a null entry root@Tower:~# xl list Name ID Mem VCPUs State Time(s) Domain-0 0 2048 8 r----- 517.9 (null) 1 0 6 --p--d 4255.6 Myk
June 20, 201412 yr ArchVM is locked solid The question has to be: What is the significant difference between those ArchVMs which exhibit this crash, and those which don't? At least one person has mentioned the Transmission daemon. I have the Deluge daemon auto launching on the VM which crashes. What about others? Are those of you experiencing this problem running a bittorrent client/daemon in your VM?
June 20, 201412 yr ArchVM is locked solid The question has to be: What is the significant difference between those ArchVMs which exhibit this crash, and those which don't? At least one person has mentioned the Transmission daemon. I have the Deluge daemon auto launching on the VM which crashes. What about others? Are those of you experiencing this problem running a bittorrent client/daemon in your VM? My Lubuntu VM runs Sick/SAB & Headphones and never crashes My windows 8.1 VM only runs Plex and crashes within 5 minutes
June 20, 201412 yr I'm relatively new to the Unraid community, but I was curios, does it matter that he has two bootloaders in his config file even though they are the same? Seems redundant, unnecessary, and could possibly cause an error? Good catch, I removed the duplicate bootloader line and tried again. Same results, but still a good catch.
June 20, 201412 yr ArchVM is locked solid The question has to be: What is the significant difference between those ArchVMs which exhibit this crash, and those which don't? At least one person has mentioned the Transmission daemon. I have the Deluge daemon auto launching on the VM which crashes. What about others? Are those of you experiencing this problem running a bittorrent client/daemon in your VM? My vm was not Arch, it was Ubuntu Server 12.04.4 LTS. I was not running transmission though or any bittorrent client on this vm.
June 20, 201412 yr I have been running 5a with a Ubuntu 12.04 server VM. On the server I have Apache, Mysql, Newznab, Sickbeard, Couchpotato and SabNZBD. After upgrading to Beta 6, I lost the ability to connect to these media apps via my web browser and Newznab was unable to connect to my Usenet news server. I updated by copying bzimage, bzroot and zen to my flash drive. Unraid booted and the VM loaded (I didn't change my Xen configuration and started the VM using the web GUI) but apparently there is a network problem. Did I miss a step? Thanks.
June 20, 201412 yr I did mention in the origional Beta6 thread....My ArchVM survives until I run Mount -a, followed by transmission-daemon. Once running I only have about 5min till crash! After which I have the same error as Sandorr Jun 19 09:56:20 test kernel: kernel BUG at drivers/net/xen-netback/netback.c:629!
June 20, 201412 yr Just for the sake of argument, I reverted back to unRAID 6 Beta 5a and was able to bring up the VM without issues. I wanted to rule out anything that just happend to go wrong right at the time I switched to unRAID 6 Beta 6. So this is definatly something wonky with unRAID 6 Beta 6 and XEN.
June 20, 201412 yr I am running Ironic's archVM (v3) with SAB, SB, Plex and MariaDB. Everything had been running fine for about 24 hours, but since others were reporting issues I tried pacman -Syyu which upgraded the Linux kernel to 3.15.1. When I got up this morning all the consoles were unresponsive. I was still in the VM via putty and was able to try and reboot, but the VM failed to restart. I tried 'xl create archVM' and got a message that it couldn't capture memory (I am an idiot and didn't write the screenshot text down). I rebooted UnRAID and the VM started again okay. If it crashes again I will get better notes. Bottom line is I was fine until I updated the VM. Not sure if the new kernel is the culprit, but it seems more likely than the other small packages it updated.
June 20, 201412 yr I am running Ironic's archVM (v3) with SAB, SB, Plex and MariaDB. Everything had been running fine for about 24 hours, but since others were reporting issues I tried pacman -Syyu which upgraded the Linux kernel to 3.15.1. When I got up this morning all the consoles were unresponsive. I was still in the VM via putty and was able to try and reboot, but the VM failed to restart. I tried 'xl create archVM' and got a message that it couldn't capture memory (I am an idiot and didn't write the screenshot text down). I rebooted UnRAID and the VM started again okay. If it crashes again I will get better notes. Bottom line is I was fine until I updated the VM. Not sure if the new kernel is the culprit, but it seems more likely than the other small packages it updated. do you have this same entry in your syslog? Jun 19 09:56:20 test kernel: kernel BUG at drivers/net/xen-netback/netback.c:629!
June 20, 201412 yr What I get if I get to the console is: [ 132.671107] xen_netfront: xennet: skb rides the rocket: 19 slots [ 1217.871974] xen_netfront: xennet: skb rides the rocket: 19 slots [ 1218.290767] xen_netfront: xennet: skb rides the rocket: 19 slots Screen is just filled with them - SabNzbd, Sickbeard, and Plex are all i am running - last beta I got intermittent rocket errors but never lost the VM Myk ArchVM is locked solid The question has to be: What is the significant difference between those ArchVMs which exhibit this crash, and those which don't? At least one person has mentioned the Transmission daemon. I have the Deluge daemon auto launching on the VM which crashes. What about others? Are those of you experiencing this problem running a bittorrent client/daemon in your VM?
June 20, 201412 yr Author This issue is definitely 100% Xen related and has yet to be solved. This isn't UnRaid or our configuration of Xen. This has been a bug that has existed since 3.8 Linux kernel and keeps coming back. We are stuck waiting for a fix, but in the meantime, we haven't had these issues with docker or KVM. Sent from my Nexus 5 using Tapatalk
Archived
This topic is now archived and is closed to further replies.