Re: Bug in virtio-net
On Mon, Dec 8, 2014 at 5:34 PM, Shawn Webb wrote: > I was running Poudriere in bhyve. I got this kernel panic. I'm on a new > 11-CURRENT as of this morning. Would this be a NULL pointer deref? > > `uname -a`: FreeBSD 11.0-CURRENT FreeBSD 11.0-CURRENT #1 > b5310d8(hardened/current/master)-dirty: Mon Dec 8 12:58:12 UTC 2014 > shawn@pkg-build-01:/usr/obj/usr/src/sys/LATT-SEC amd64 > > This bhyve VM is at r275606. The host is at r275575. > > Thanks, > > Shawn > > Kern panic backtrace: > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x0 > fault code = supervisor read instruction, page not present > instruction pointer = 0x20:0x0 > stack pointer = 0x28:0xfe0469a0c830 > frame pointer = 0x28:0xfe0469a0c8b0 > code segment= base 0x0, limit 0xf, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags= interrupt enabled, resume, IOPL = 0 > current process = 12 (irq267: virtio_pci0) > [ thread pid 12 tid 100040 ] > Stopped at 0:KDB: reentering > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > 0xfe0469a0bd90 > kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe0469a0be40 > kdb_reenter() at kdb_reenter+0x33/frame 0xfe0469a0be50 > trap() at trap+0x54/frame 0xfe0469a0c060 > calltrap() at calltrap+0x8/frame 0xfe0469a0c060 > --- trap 0xc, rip = 0x80e06033, rsp = 0xfe0469a0c120, rbp = > 0xfe0469a0c1c0 --- > db_read_bytes() at db_read_bytes+0x53/frame 0xfe0469a0c1c0 > db_get_value() at db_get_value+0x38/frame 0xfe0469a0c210 > db_disasm() at db_disasm+0x23/frame 0xfe0469a0c330 > db_trap() at db_trap+0xc0/frame 0xfe0469a0c3c0 > kdb_trap() at kdb_trap+0x191/frame 0xfe0469a0c460 > trap_fatal() at trap_fatal+0x34c/frame 0xfe0469a0c4c0 > trap_pfault() at trap_pfault+0x33c/frame 0xfe0469a0c560 > trap() at trap+0x45e/frame 0xfe0469a0c770 > calltrap() at calltrap+0x8/frame 0xfe0469a0c770 > --- trap 0xc, rip = 0, rsp = 0xfe0469a0c830, rbp = > 0xfe0469a0c8b0 --- > uart_sab82532_class() at 0/frame 0xfe0469a0c8b0 > ether_input() at ether_input+0x26/frame 0xfe0469a0c8d0 > vtnet_rxq_eof() at vtnet_rxq_eof+0x7be/frame 0xfe0469a0c9a0 > vtnet_rx_vq_intr() at vtnet_rx_vq_intr+0x94/frame 0xfe0469a0c9e0 > intr_event_execute_handlers() at intr_event_execute_handlers+0x1b8/frame > 0xfe0469a0ca20 > ithread_loop() at ithread_loop+0x96/frame 0xfe0469a0ca70 > fork_exit() at fork_exit+0x9a/frame 0xfe0469a0cab0 > fork_trampoline() at fork_trampoline+0xe/frame 0xfe0469a0cab0 > --- trap 0, rip = 0, rsp = 0xfe0469a0cb70, rbp = 0 --- > I doubt this has anything to do with vtnet. My guess is that netisr_proto[NETISR_ETHER].np_handler(m) is NULL for some reason. Do you have a dump? > *** error reading from address 0 *** > KDB: reentering > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > 0xfe0469a0c100 > kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe0469a0c1b0 > kdb_reenter() at kdb_reenter+0x33/frame 0xfe0469a0c1c0 > db_get_value() at db_get_value+0x52/frame 0xfe0469a0c210 > db_disasm() at db_disasm+0x23/frame 0xfe0469a0c330 > db_trap() at db_trap+0xc0/frame 0xfe0469a0c3c0 > kdb_trap() at kdb_trap+0x191/frame 0xfe0469a0c460 > trap_fatal() at trap_fatal+0x34c/frame 0xfe0469a0c4c0 > trap_pfault() at trap_pfault+0x33c/frame 0xfe0469a0c560 > trap() at trap+0x45e/frame 0xfe0469a0c770 > calltrap() at calltrap+0x8/frame 0xfe0469a0c770 > --- trap 0xc, rip = 0, rsp = 0xfe0469a0c830, rbp = > 0xfe0469a0c8b0 --- > uart_sab82532_class() at 0/frame 0xfe0469a0c8b0 > ether_input() at ether_input+0x26/frame 0xfe0469a0c8d0 > vtnet_rxq_eof() at vtnet_rxq_eof+0x7be/frame 0xfe0469a0c9a0 > vtnet_rx_vq_intr() at vtnet_rx_vq_intr+0x94/frame 0xfe0469a0c9e0 > intr_event_execute_handlers() at intr_event_execute_handlers+0x1b8/frame > 0xfe0469a0ca20 > ithread_loop() at ithread_loop+0x96/frame 0xfe0469a0ca70 > fork_exit() at fork_exit+0x9a/frame 0xfe0469a0cab0 > fork_trampoline() at fork_trampoline+0xe/frame 0xfe0469a0cab0 > --- trap 0, rip = 0, rsp = 0xfe0469a0cb70, rbp = 0 --- > > ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
Re: backups of bhyve images
Hi John, Basically, what I want to do is to run accurate backups without shutting down and restarting the VM. Is this possible? If it isn't, I think the only alternative is to make a script that shuts the vm down, copies it, restarts the vm then runs its compression and backup-over-ssh routine. It's not possible in the general case to take a snapshot of the underlying image since as others have pointed out, it may not be consistent on disk since there are still data/metadata from the guest's filesystem that haven't made it out to disk. Commercial hypervisors provide guest tools that allow a filesystem quiesce/sync that lock-steps with external snapshotting machinery. However, one option that could be worth investigating is using ZFS in the guest with disk images backed by a zvol on the host. ZFS guarantees on-disk consistency, and a zvol provides instantaneous snapshots. Worst case is that some writes are not picked up at snapshot time, but that seems preferable to having to force a full sync in the guest. later, Peter. ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
Re: backups of bhyve images
On 12/08/14 15:30, Craig Rodrigues wrote: > (3) When you want to backup the VM, do a "zfs snapshot" take take a > snapshot of the ZFS zvol. will this ensure that your zvol is consistent, or rather will the filesystem overlaid on the zvol device be ensured it is consistent when the hypervisor issues a snapshot command? it's been a while since i've done this - but IIRC on NetApp WAFL systems (which are similar to zfs in terms of being a COW filesystem) you need to ensure the guest filesystem is in a consistent state before issuing a snapshot from it's parent. my data may be out of date since it's been several years since i've done this though... cheers, -pete -- Pete Wright p...@nomadlogic.org twitter => @nomadlogicLA ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
Bug in virtio-net
I was running Poudriere in bhyve. I got this kernel panic. I'm on a new 11-CURRENT as of this morning. Would this be a NULL pointer deref? `uname -a`: FreeBSD 11.0-CURRENT FreeBSD 11.0-CURRENT #1 b5310d8(hardened/current/master)-dirty: Mon Dec 8 12:58:12 UTC 2014 shawn@pkg-build-01:/usr/obj/usr/src/sys/LATT-SEC amd64 This bhyve VM is at r275606. The host is at r275575. Thanks, Shawn Kern panic backtrace: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x0 fault code = supervisor read instruction, page not present instruction pointer = 0x20:0x0 stack pointer = 0x28:0xfe0469a0c830 frame pointer = 0x28:0xfe0469a0c8b0 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 12 (irq267: virtio_pci0) [ thread pid 12 tid 100040 ] Stopped at 0:KDB: reentering KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe0469a0bd90 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe0469a0be40 kdb_reenter() at kdb_reenter+0x33/frame 0xfe0469a0be50 trap() at trap+0x54/frame 0xfe0469a0c060 calltrap() at calltrap+0x8/frame 0xfe0469a0c060 --- trap 0xc, rip = 0x80e06033, rsp = 0xfe0469a0c120, rbp = 0xfe0469a0c1c0 --- db_read_bytes() at db_read_bytes+0x53/frame 0xfe0469a0c1c0 db_get_value() at db_get_value+0x38/frame 0xfe0469a0c210 db_disasm() at db_disasm+0x23/frame 0xfe0469a0c330 db_trap() at db_trap+0xc0/frame 0xfe0469a0c3c0 kdb_trap() at kdb_trap+0x191/frame 0xfe0469a0c460 trap_fatal() at trap_fatal+0x34c/frame 0xfe0469a0c4c0 trap_pfault() at trap_pfault+0x33c/frame 0xfe0469a0c560 trap() at trap+0x45e/frame 0xfe0469a0c770 calltrap() at calltrap+0x8/frame 0xfe0469a0c770 --- trap 0xc, rip = 0, rsp = 0xfe0469a0c830, rbp = 0xfe0469a0c8b0 --- uart_sab82532_class() at 0/frame 0xfe0469a0c8b0 ether_input() at ether_input+0x26/frame 0xfe0469a0c8d0 vtnet_rxq_eof() at vtnet_rxq_eof+0x7be/frame 0xfe0469a0c9a0 vtnet_rx_vq_intr() at vtnet_rx_vq_intr+0x94/frame 0xfe0469a0c9e0 intr_event_execute_handlers() at intr_event_execute_handlers+0x1b8/frame 0xfe0469a0ca20 ithread_loop() at ithread_loop+0x96/frame 0xfe0469a0ca70 fork_exit() at fork_exit+0x9a/frame 0xfe0469a0cab0 fork_trampoline() at fork_trampoline+0xe/frame 0xfe0469a0cab0 --- trap 0, rip = 0, rsp = 0xfe0469a0cb70, rbp = 0 --- *** error reading from address 0 *** KDB: reentering KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe0469a0c100 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe0469a0c1b0 kdb_reenter() at kdb_reenter+0x33/frame 0xfe0469a0c1c0 db_get_value() at db_get_value+0x52/frame 0xfe0469a0c210 db_disasm() at db_disasm+0x23/frame 0xfe0469a0c330 db_trap() at db_trap+0xc0/frame 0xfe0469a0c3c0 kdb_trap() at kdb_trap+0x191/frame 0xfe0469a0c460 trap_fatal() at trap_fatal+0x34c/frame 0xfe0469a0c4c0 trap_pfault() at trap_pfault+0x33c/frame 0xfe0469a0c560 trap() at trap+0x45e/frame 0xfe0469a0c770 calltrap() at calltrap+0x8/frame 0xfe0469a0c770 --- trap 0xc, rip = 0, rsp = 0xfe0469a0c830, rbp = 0xfe0469a0c8b0 --- uart_sab82532_class() at 0/frame 0xfe0469a0c8b0 ether_input() at ether_input+0x26/frame 0xfe0469a0c8d0 vtnet_rxq_eof() at vtnet_rxq_eof+0x7be/frame 0xfe0469a0c9a0 vtnet_rx_vq_intr() at vtnet_rx_vq_intr+0x94/frame 0xfe0469a0c9e0 intr_event_execute_handlers() at intr_event_execute_handlers+0x1b8/frame 0xfe0469a0ca20 ithread_loop() at ithread_loop+0x96/frame 0xfe0469a0ca70 fork_exit() at fork_exit+0x9a/frame 0xfe0469a0cab0 fork_trampoline() at fork_trampoline+0xe/frame 0xfe0469a0cab0 --- trap 0, rip = 0, rsp = 0xfe0469a0cb70, rbp = 0 --- signature.asc Description: This is a digitally signed message part
Re: backups of bhyve images
On Dec 8, 2014, at 8:33 AM, John wrote: > > I have each image on its own (external to the image) ZFS filesystem. > Internally the image is using ufs if freebsd, ext3fs if linux. Would > using some ZFS method of duplication be better? In this case, would the > image become inconsistent? I recommend that you do the following: (1) Learn about ZFS zvol: http://zfsonlinux.org/example-zvol.html (2) Instead of creating a big disk image to hold your bhyve VM, use a ZFS zvol (3) When you want to backup the VM, do a "zfs snapshot" take take a snapshot of the ZFS zvol. (4) You can backup the zvol to another host by using "zfs send", and onthe receiving host, you do "zfs receive" The content of your VM can be any file system that you want (UFS, ext4, zfs), but you can backup the ZFS zvol using zfs commands. I've been doing it, and it works really nicely. -- Craig ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
Re: backups of bhyve images
On Dec 8, 2014, at 8:33 AM, John wrote: > Hello list, > > I have a few questions about creating backups to be stored offsite. > > If a guest is running, can I compress the image without it becoming > inconsistent? If not, can it be copied without it becoming inconsistent? > By inconsistent, I mean will I see weird effects and broken files if the > backup is restored? Previously I've shut the VM down to avoid this, > before archiving. > > I have each image on its own (external to the image) ZFS filesystem. > Internally the image is using ufs if freebsd, ext3fs if linux. Would > using some ZFS method of duplication be better? In this case, would the > image become inconsistent? > > Basically, what I want to do is to run accurate backups without shutting > down and restarting the VM. Is this possible? If it isn't, I think the > only alternative is to make a script that shuts the vm down, copies it, > restarts the vm then runs its compression and backup-over-ssh routine. [[ adding f...@freebsd.org in case I'm wrong ]] If you are using UFS internally to the VMs then you'll need to send a snapshot that is consistent. If you are just copying the files out from under a running vm you are going to get spaghettios for a filesystem if you try to recover as you need a true point in time snapshot. I think a few better options would be: 1) Inside the VM create a UFS snapshot then dump that externally using tools. 2) Create the UFS snapshot, then make sure that the file/vzol is snapshotted using zfs. 3) Just snapshot the underlying zvol you've made the UFS image on and send that (you'll get a dirty FS on restore, but it *should* be recoverable with a simple fsck) 4) Use zfs internally to the vm and send/receive the internal zfs. option 3 is the least safe imo as you can wind up with filesystem "angry". in case 1 and 2 you'll have UFS snapshots that should be "OK" to restore from. in case 4 you are also doing snapshot, but you switch to ZFS. -Alfred ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
[Bug 147950] [vimage] [carp] VIMAGE + CARP = kernel crash
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=147950 Craig Rodrigues changed: What|Removed |Added Status|In Progress |Closed CC||rodr...@freebsd.org Resolution|--- |DUPLICATE --- Comment #7 from Craig Rodrigues --- *** This bug has been marked as a duplicate of bug 164696 *** -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
[Bug 160496] [vimage] [pf] [patch] kernel panic with pf + VIMAGE
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=160496 Craig Rodrigues changed: What|Removed |Added CC||titi5...@gmail.com --- Comment #4 from Craig Rodrigues --- *** Bug 182350 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
[Bug 165252] [vimage] [pf] [panic] kernel panics with VIMAGE and PF on FreeBSD 9.0 rel
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=165252 Craig Rodrigues changed: What|Removed |Added Status|In Progress |Closed CC||rodr...@freebsd.org Resolution|--- |DUPLICATE --- Comment #4 from Craig Rodrigues --- *** This bug has been marked as a duplicate of bug 160496 *** -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
[Bug 160496] [vimage] [pf] [patch] kernel panic with pf + VIMAGE
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=160496 Craig Rodrigues changed: What|Removed |Added CC||robrob2...@yahoo.com --- Comment #3 from Craig Rodrigues --- *** Bug 165252 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
backups of bhyve images
Hello list, I have a few questions about creating backups to be stored offsite. If a guest is running, can I compress the image without it becoming inconsistent? If not, can it be copied without it becoming inconsistent? By inconsistent, I mean will I see weird effects and broken files if the backup is restored? Previously I've shut the VM down to avoid this, before archiving. I have each image on its own (external to the image) ZFS filesystem. Internally the image is using ufs if freebsd, ext3fs if linux. Would using some ZFS method of duplication be better? In this case, would the image become inconsistent? Basically, what I want to do is to run accurate backups without shutting down and restarting the VM. Is this possible? If it isn't, I think the only alternative is to make a script that shuts the vm down, copies it, restarts the vm then runs its compression and backup-over-ssh routine. thanks, -- John ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"