Re: HEADS UP: Imported Xen 4.7: no blkback
On Thu, 16 Jun 2016, Roger Pau Monné wrote: > I've just imported Xen 4.7.0-rc6 into the ports tree, could you give it a > try when you have a moment? Yes, of course. A quick test shows no change - Windows get stuck at the UEFI shell with some block devices listed (I use "hda" for Windows), SeaBIOS cannot boot FreeBSD with "xvda". FreeBSD works with "hda", but I have to mount "/dev/ada0p1". Marcin ___ freebsd-virtualization@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
Re: HEADS UP: Imported Xen 4.7: no blkback
On Mon, Jun 13, 2016 at 07:26:30PM +, Marcin Cieslak wrote: > On Mon, 13 Jun 2016, Roger Pau Monné wrote: > > > On Fri, Jun 10, 2016 at 09:38:59PM +, Marcin Cieslak wrote: > > > "?" does not work - it mostly causes a panic, the console is slow, but I > > > managed > > > to switch it to /dev/ada0p2, dmesg below: > > > > This has now been reverted, so when I import the new RC this should be > > fixed > > and you won't need to change anything. > > I am confused now - so with a new Xen kernel (not yet in ports) I can use > /dev/xbd* devices again? They are in fact missing - xbd driver says > "attaching as ada0" > and I can mount it only as /dev/ada > > > It seems like Windows PV drivers don't attach at all, or are you running > > Windows without the PV drivers? > > Yes, I have. Those Windows partitions used to work properly without changes > under xen 4.5. But we are too early - the problem is that even ovmf > does not se them drives now, this is before Windows boots. > > > Since you mention that the console is very slow, if you run 'top' on Dom0, > > do you see any process (eg: qemu) taking a lot of CPU time? > > Yes, > > 1635 root 7 1000 241M 101M RUN 7:16 91.14% > qemu-system-i386 > > or more > > > Also, do you see Dom0 consuming a lot of CPU if you run 'xentop'? > > Domain-0 -r446 100.04194300 25.2 no limit n/a > 10000000 0 > 00 > Hello, I've just imported Xen 4.7.0-rc6 into the ports tree, could you give it a try when you have a moment? FWIW, I'm going on vacations until the 4th of July, and I will be mostly AFK. Roger. ___ freebsd-virtualization@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
Re: HEADS UP: Imported Xen 4.7: no blkback
On Mon, 13 Jun 2016, Roger Pau Monné wrote: > On Fri, Jun 10, 2016 at 09:38:59PM +, Marcin Cieslak wrote: > > "?" does not work - it mostly causes a panic, the console is slow, but I > > managed > > to switch it to /dev/ada0p2, dmesg below: > > This has now been reverted, so when I import the new RC this should be fixed > and you won't need to change anything. I am confused now - so with a new Xen kernel (not yet in ports) I can use /dev/xbd* devices again? They are in fact missing - xbd driver says "attaching as ada0" and I can mount it only as /dev/ada > It seems like Windows PV drivers don't attach at all, or are you running > Windows without the PV drivers? Yes, I have. Those Windows partitions used to work properly without changes under xen 4.5. But we are too early - the problem is that even ovmf does not se them drives now, this is before Windows boots. > Since you mention that the console is very slow, if you run 'top' on Dom0, > do you see any process (eg: qemu) taking a lot of CPU time? Yes, 1635 root 7 1000 241M 101M RUN 7:16 91.14% qemu-system-i386 or more > Also, do you see Dom0 consuming a lot of CPU if you run 'xentop'? Domain-0 -r446 100.04194300 25.2 no limit n/a 10000000 0 0 0 Marcin ___ freebsd-virtualization@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
Re: HEADS UP: Imported Xen 4.7: no blkback
On Mon, 13 Jun 2016, Roger Pau Monné wrote: > Since you mention that the console is very slow, if you run 'top' on Dom0, > do you see any process (eg: qemu) taking a lot of CPU time? > > Also, do you see Dom0 consuming a lot of CPU if you run 'xentop'? Just quick info regarding console problem at the mountroot prompt: - it was also very slow and behaving strange with older kernel and 4.5.2. - it works better when I use dual console - one can type on the serial console and see the results immediately, vidconsole is slower but thins seem to work (at least I get no panics due to "cannot mount root" anymore). - will check top Marcin ___ freebsd-virtualization@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
Re: HEADS UP: Imported Xen 4.7: no blkback
On Fri, Jun 10, 2016 at 09:38:59PM +, Marcin Cieslak wrote: > On Thu, 9 Jun 2016, Roger Pau Monné wrote: > > > On Thu, Jun 09, 2016 at 12:16:59AM +, Marcin Cieslak wrote: > > > On Fri, 3 Jun 2016, Roger Pau Monné wrote: > > > > > > > One of the more relevant changes in 4.7 regarding FreeBSD is the > > > > support for > > > > block hotplug scripts. This means that we now have the option to use > > > > backends different than simple block or regular files, provided that > > > > someone > > > > writes the proper hotplug scripts to attach them (I've heard there are > > > > some > > > > iSCSI hotplug scripts around). This however requires changes in > > > > blkback, so > > > > if you plan to use the Xen 4.7 port, please make sure that you are > > > > running a > > > > kernel that contains revision r301269 (or any later version). The same > > > > also > > > > > > I am running it with r301685 and the HVM guests have some trouble with > > > block devices. > > > > > > SeaBIOS does not find /dev/zvol/zroot/freebsd1,raw,xvda,w to boot FreeBSD > > > from, after chaging to "hda" I get up to the kernel mountroot prompt > > > (Xen block devices seem to be detected in dmesg). > > > > Yes, this is intentional, see: > > > > https://marc.info/?l=xen-devel&m=144482080812353 > > those guests worked fine with 4.5, that's why I am surprised. > > xbd0 and xbd1 show up in dmesg, mouting root from xbd0p2 fails, but > ada0p2 seems to work. > > I remember that during my previous attempts ZFS ate most of > my machine's memory (dom0 was too small I think) and the > symptom was very similar if not identical. > > One thing which struck me is that I was able to fully but > one Linux HVM domU. I am also toying with OpenFirmware > which boots from floppy as a HVM guest. > > > Have you checked if you need to change your /etc/fstab to correctly point > > to the new device? Does FreeBSD correctly list the disk(s) at the mountroot > > prompt when issuing a "?" command? > > "?" does not work - it mostly causes a panic, the console is slow, but I > managed > to switch it to /dev/ada0p2, dmesg below: This has now been reverted, so when I import the new RC this should be fixed and you won't need to change anything. > Copyright (c) 1992-2016 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 11.0-CURRENT #1 r298620: Tue Apr 26 13:21:50 UTC 2016 > r...@o.saper.info:/usr/obj/usr/src/sys/GENERIC amd64 > FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based on LLVM > 3.8.0) > WARNING: WITNESS option enabled, expect reduced performance. > VT(vga): text 80x25 > XEN: Hypervisor version 4.7 detected. > CPU: Intel(R) Xeon(R) CPU E31245 @ 3.30GHz (3300.08-MHz K8-class CPU) > Origin="GenuineIntel" Id=0x206a7 Family=0x6 Model=0x2a Stepping=7 > > Features=0x17c3fbff > > Features2=0x9fba2203 > AMD Features=0x28100800 > AMD Features2=0x1 > XSAVE Features=0x1 > Hypervisor: Origin = "XenVMMXenVMM" > real memory = 2130706432 (2032 MB) > avail memory = 2018213888 (1924 MB) > Event timer "LAPIC" quality 400 > ACPI APIC Table: > WARNING: L1 data cache covers less APIC IDs than a core > 0 < 1 > WARNING: L2 data cache covers less APIC IDs than a core > 0 < 1 > WARNING: L3 data cache covers less APIC IDs than a core > 0 < 1 > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > FreeBSD/SMP: 1 package(s) x 2 core(s) > random: unblocking device. > ioapic0: Changing APIC ID to 1 > MADT: Forcing active-low polarity and level trigger for SCI > ioapic0 irqs 0-47 on motherboard > random: entropy device external interface > kbd1 at kbdmux0 > netmap: loaded module > module_register_init: MOD_LOAD (vesa, 0x80f0ffb0, 0) error 19 > vtvga0: on motherboard > cryptosoft0: on motherboard > acpi0: on motherboard > acpi0: Power Button (fixed) > acpi0: Sleep Button (fixed) > cpu0: on acpi0 > cpu1: on acpi0 > hpet0: iomem 0xfed0-0xfed003ff on acpi0 > Timecounter "HPET" frequency 6250 Hz quality 950 > attimer0: port 0x40-0x43 irq 0 on acpi0 > Timecounter "i8254" frequency 1193182 Hz quality 0 > Event timer "i8254" frequency 1193182 Hz quality 100 > atrtc0: port 0x70-0x71 irq 8 on acpi0 > Event timer "RTC" frequency 32768 Hz quality 0 > Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 > acpi_timer0: <32-bit timer at 3.579545MHz> port 0xb008-0xb00b on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > isab0: at device 1.0 on pci0 > isa0: on isab0 > atapci0: port > 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xc200-0xc20f at device 1.1 on pci0 > ata0: at channel 0 on atapci0 > ata1: at channel 1 on atapci0 > pci0: at device 1.3 (no driver attached) > xenpci0: port 0xc000-0xc0ff mem 0xf000-0xf0ff > irq 24 at device 2.0 on pci0 > vgapci0: mem > 0xf100-0xf1ff,0xf205-
Re: HEADS UP: Imported Xen 4.7: no blkback
On Thu, 9 Jun 2016, Roger Pau Monné wrote: > On Thu, Jun 09, 2016 at 12:16:59AM +, Marcin Cieslak wrote: > > On Fri, 3 Jun 2016, Roger Pau Monné wrote: > > > > > One of the more relevant changes in 4.7 regarding FreeBSD is the support > > > for > > > block hotplug scripts. This means that we now have the option to use > > > backends different than simple block or regular files, provided that > > > someone > > > writes the proper hotplug scripts to attach them (I've heard there are > > > some > > > iSCSI hotplug scripts around). This however requires changes in blkback, > > > so > > > if you plan to use the Xen 4.7 port, please make sure that you are > > > running a > > > kernel that contains revision r301269 (or any later version). The same > > > also > > > > I am running it with r301685 and the HVM guests have some trouble with > > block devices. > > > > SeaBIOS does not find /dev/zvol/zroot/freebsd1,raw,xvda,w to boot FreeBSD > > from, after chaging to "hda" I get up to the kernel mountroot prompt > > (Xen block devices seem to be detected in dmesg). > > Yes, this is intentional, see: > > https://marc.info/?l=xen-devel&m=144482080812353 those guests worked fine with 4.5, that's why I am surprised. xbd0 and xbd1 show up in dmesg, mouting root from xbd0p2 fails, but ada0p2 seems to work. I remember that during my previous attempts ZFS ate most of my machine's memory (dom0 was too small I think) and the symptom was very similar if not identical. One thing which struck me is that I was able to fully but one Linux HVM domU. I am also toying with OpenFirmware which boots from floppy as a HVM guest. > Have you checked if you need to change your /etc/fstab to correctly point > to the new device? Does FreeBSD correctly list the disk(s) at the mountroot > prompt when issuing a "?" command? "?" does not work - it mostly causes a panic, the console is slow, but I managed to switch it to /dev/ada0p2, dmesg below: Copyright (c) 1992-2016 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 11.0-CURRENT #1 r298620: Tue Apr 26 13:21:50 UTC 2016 r...@o.saper.info:/usr/obj/usr/src/sys/GENERIC amd64 FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based on LLVM 3.8.0) WARNING: WITNESS option enabled, expect reduced performance. VT(vga): text 80x25 XEN: Hypervisor version 4.7 detected. CPU: Intel(R) Xeon(R) CPU E31245 @ 3.30GHz (3300.08-MHz K8-class CPU) Origin="GenuineIntel" Id=0x206a7 Family=0x6 Model=0x2a Stepping=7 Features=0x17c3fbff Features2=0x9fba2203 AMD Features=0x28100800 AMD Features2=0x1 XSAVE Features=0x1 Hypervisor: Origin = "XenVMMXenVMM" real memory = 2130706432 (2032 MB) avail memory = 2018213888 (1924 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: WARNING: L1 data cache covers less APIC IDs than a core 0 < 1 WARNING: L2 data cache covers less APIC IDs than a core 0 < 1 WARNING: L3 data cache covers less APIC IDs than a core 0 < 1 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) random: unblocking device. ioapic0: Changing APIC ID to 1 MADT: Forcing active-low polarity and level trigger for SCI ioapic0 irqs 0-47 on motherboard random: entropy device external interface kbd1 at kbdmux0 netmap: loaded module module_register_init: MOD_LOAD (vesa, 0x80f0ffb0, 0) error 19 vtvga0: on motherboard cryptosoft0: on motherboard acpi0: on motherboard acpi0: Power Button (fixed) acpi0: Sleep Button (fixed) cpu0: on acpi0 cpu1: on acpi0 hpet0: iomem 0xfed0-0xfed003ff on acpi0 Timecounter "HPET" frequency 6250 Hz quality 950 attimer0: port 0x40-0x43 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 atrtc0: port 0x70-0x71 irq 8 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <32-bit timer at 3.579545MHz> port 0xb008-0xb00b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 isab0: at device 1.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xc200-0xc20f at device 1.1 on pci0 ata0: at channel 0 on atapci0 ata1: at channel 1 on atapci0 pci0: at device 1.3 (no driver attached) xenpci0: port 0xc000-0xc0ff mem 0xf000-0xf0ff irq 24 at device 2.0 on pci0 vgapci0: mem 0xf100-0xf1ff,0xf205-0xf2050fff at device 3.0 on pci0 vgapci0: Boot video device atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model IntelliMouse Explorer, device ID 4 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: does not respond device_attach: fdc0 attach returned 6 xenpv0: on motherboard granttable0: on xenpv0 xen_e
Re: HEADS UP: Imported Xen 4.7: no blkback
On Thu, Jun 09, 2016 at 12:16:59AM +, Marcin Cieslak wrote: > On Fri, 3 Jun 2016, Roger Pau Monné wrote: > > > One of the more relevant changes in 4.7 regarding FreeBSD is the support > > for > > block hotplug scripts. This means that we now have the option to use > > backends different than simple block or regular files, provided that > > someone > > writes the proper hotplug scripts to attach them (I've heard there are some > > iSCSI hotplug scripts around). This however requires changes in blkback, so > > if you plan to use the Xen 4.7 port, please make sure that you are running > > a > > kernel that contains revision r301269 (or any later version). The same also > > I am running it with r301685 and the HVM guests have some trouble with > block devices. > > SeaBIOS does not find /dev/zvol/zroot/freebsd1,raw,xvda,w to boot FreeBSD > from, after chaging to "hda" I get up to the kernel mountroot prompt > (Xen block devices seem to be detected in dmesg). Yes, this is intentional, see: https://marc.info/?l=xen-devel&m=144482080812353 Have you checked if you need to change your /etc/fstab to correctly point to the new device? Does FreeBSD correctly list the disk(s) at the mountroot prompt when issuing a "?" command? Also, can you paste the output of `xenstore-ls -fp` from Dom0 when this happens? > What used to be Windows 2016 domU with /dev/zvol/zroot/windows0,raw,hda,w > ends up in the Tianocore UEFI shell. Block devices seem to be available, > I can even list the fs0: partition, but no booting further possible. Hm, I've never used Tianocore myself, so I'm not sure what the issue could be here. Again, can you post the output of `xenstore-ls -fp` from Dom0 when this happens? At least this will show if the PV block device has been correctly attached. Roger. ___ freebsd-virtualization@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
Re: HEADS UP: Imported Xen 4.7 and blkback changes - domU respawning on_crash
On Wed, Jun 08, 2016 at 10:35:22PM +, Marcin Cieslak wrote: > On Wed, 8 Jun 2016, Marcin Cieslak wrote: > > > On Fri, 3 Jun 2016, Roger Pau Monné wrote: > > > > > Hello, > > > > > > First of all, this message is only relevant to those that use FreeBSD as > > > Dom0 (host), not as a DomU (guest), so don't panic. > > > > > > I've imported the latest Xen version (4.7-rc4) into the ports tree, it's > > > still not the final version, but it's quite close, so we better start > > > testing it to make sure it works fine with FreeBSD. > > One issue maybe unrelated to FreeBSD: > > This domain: > > builder = "hvm" > memory = 4096 > vcpus = 2 > name = "Windows2016" > disk = [ > '/dev/zvol/zroot/windows0,raw,hda,w', > '/dev/zvol/zroot/vs2013,raw,hdb,w', > #'/root/win/install.iso,raw,hdc:cdrom,r' > ] > boot = "c" # Boot to hard disk image > vnc = 2 > #vnclisten = "0.0.0.0" > usbdevice = 'tablet' > on_poweroff = 'destroy' > on_reboot = 'restart' > on_crash = 'restart' > acpi = 1 > bios = 'ovmf' > vif = [ 'bridge=bridge0,mac=00:16:3e:5d:0d:48' ] > videoram=16 > vga = "stdvga" > > crashes because I didn't have ovmf image: > > (d203) HVM Loader > (d203) Detected Xen v4.7.0-rc > (d203) Xenbus rings @0xfeffc000, event channel 1 > (d203) Unknown BIOS ovmf, no ROM image found > (d203) *** HVMLoader bug at hvmloader.c:229 > (d203) *** HVMLoader crashed. > > But I seem unable to kill it with "xl destroy" - it keeps > respawning again: > > Windows2016211 4079 1 --p--- > 0.0 > Windows2016213 4096 1 --psc- > 0.0 > (disappears) > Windows2016221 4096 1 --psc- > 0.0 > (null) 221 147 1 --psc- > 0.0 > ... > ... > > I have finally managed to snatch it by issuing this a few times, after > changing the "on_crash" to 'destroy': > > # xl config-update Windows2016 xen/windows-run.cfg > WARNING: xl now has better capability to manage domain configuration, avoid > using this command when possible > setting dom243 configuration The problem is that the domain crashed so early on boot that you weren't able to destroy it, and kept rebooting due to the "on_crash = 'restart'" option. IIRC I've also used the following hacky rune in order to terminate this kind of domains: "while [ 1 ]; do xl destroy ; done", but your solution seems better. Roger. ___ freebsd-virtualization@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
Re: HEADS UP: Imported Xen 4.7: no blkback
On Fri, 3 Jun 2016, Roger Pau Monné wrote: > One of the more relevant changes in 4.7 regarding FreeBSD is the support for > block hotplug scripts. This means that we now have the option to use > backends different than simple block or regular files, provided that someone > writes the proper hotplug scripts to attach them (I've heard there are some > iSCSI hotplug scripts around). This however requires changes in blkback, so > if you plan to use the Xen 4.7 port, please make sure that you are running a > kernel that contains revision r301269 (or any later version). The same also I am running it with r301685 and the HVM guests have some trouble with block devices. SeaBIOS does not find /dev/zvol/zroot/freebsd1,raw,xvda,w to boot FreeBSD from, after chaging to "hda" I get up to the kernel mountroot prompt (Xen block devices seem to be detected in dmesg). What used to be Windows 2016 domU with /dev/zvol/zroot/windows0,raw,hda,w ends up in the Tianocore UEFI shell. Block devices seem to be available, I can even list the fs0: partition, but no booting further possible. Marcin # more freebsd.cfg builder = "hvm" name = "FreeBSD" disk = [ '/dev/zvol/zroot/freebsd1,raw,xvda,w', '/dev/zvol/zroot/freebsd2,raw,xvdb,w' ] boot = "c" #usbdevice = 'tablet' #nographics = 1 serial = [ "file:/tmp/boot.log" ] vnc = 1 #vnclisten = '0.0.0.0' vif = ['bridge=bridge0,mac=00:02:04:08:fd:f0'] memory=2048 vcpus=1 vga = "cirrus" videoram = 16 # more windows-run.cfg builder = "hvm" memory = 4096 vcpus = 2 name = "Windows2016" disk = [ '/dev/zvol/zroot/windows0,raw,hda,w', '/dev/zvol/zroot/vs2013,raw,hdb,w', #'/root/win/install.iso,raw,hdc:cdrom,r' ] boot = "c" # Boot to hard disk image vnc = 2 #vnclisten = "0.0.0.0" usbdevice = 'tablet' on_poweroff = 'destroy' on_reboot = 'restart' #on_crash = 'restart' on_crash = 'destroy' acpi = 1 bios = 'ovmf' vif = [ 'bridge=bridge0,mac=00:16:3e:5d:0d:48' ] videoram=16 vga = "stdvga" ___ freebsd-virtualization@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
Re: HEADS UP: Imported Xen 4.7 and blkback changes - domU respawning on_crash
On Wed, 8 Jun 2016, Marcin Cieslak wrote: > On Fri, 3 Jun 2016, Roger Pau Monné wrote: > > > Hello, > > > > First of all, this message is only relevant to those that use FreeBSD as > > Dom0 (host), not as a DomU (guest), so don't panic. > > > > I've imported the latest Xen version (4.7-rc4) into the ports tree, it's > > still not the final version, but it's quite close, so we better start > > testing it to make sure it works fine with FreeBSD. One issue maybe unrelated to FreeBSD: This domain: builder = "hvm" memory = 4096 vcpus = 2 name = "Windows2016" disk = [ '/dev/zvol/zroot/windows0,raw,hda,w', '/dev/zvol/zroot/vs2013,raw,hdb,w', #'/root/win/install.iso,raw,hdc:cdrom,r' ] boot = "c" # Boot to hard disk image vnc = 2 #vnclisten = "0.0.0.0" usbdevice = 'tablet' on_poweroff = 'destroy' on_reboot = 'restart' on_crash = 'restart' acpi = 1 bios = 'ovmf' vif = [ 'bridge=bridge0,mac=00:16:3e:5d:0d:48' ] videoram=16 vga = "stdvga" crashes because I didn't have ovmf image: (d203) HVM Loader (d203) Detected Xen v4.7.0-rc (d203) Xenbus rings @0xfeffc000, event channel 1 (d203) Unknown BIOS ovmf, no ROM image found (d203) *** HVMLoader bug at hvmloader.c:229 (d203) *** HVMLoader crashed. But I seem unable to kill it with "xl destroy" - it keeps respawning again: Windows2016211 4079 1 --p--- 0.0 Windows2016213 4096 1 --psc- 0.0 (disappears) Windows2016221 4096 1 --psc- 0.0 (null) 221 147 1 --psc- 0.0 ... ... I have finally managed to snatch it by issuing this a few times, after changing the "on_crash" to 'destroy': # xl config-update Windows2016 xen/windows-run.cfg WARNING: xl now has better capability to manage domain configuration, avoid using this command when possible setting dom243 configuration Marcin ___ freebsd-virtualization@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
Re: Heads up
I'll try virtualbox again, but it booted fine when I tried it before. I'll give bhyve a sping. I haven't tried it in quite some time, but it worked about 9 months ago. But since I don't even know what the errors you are seeing are, I can't tell you that it is similar to some other error reports or something completely new. Warner On Sun, Apr 24, 2016 at 11:49 AM, Ivan Klymenko wrote: > On Fri, 15 Apr 2016 11:44:43 +0300 > Ivan Klymenko wrote: > > > On Thu, 14 Apr 2016 16:42:33 -0600 > > Warner Losh wrote: > > > > > The CAM I/O scheduler has been committed to current. This work is > > > described in > > > https://people.freebsd.org/~imp/bsdcan2015/iosched-v3.pdf though the > > > default scheduler doesn't change the default (old) behavior. > > > > > > One possible issue, however, is that it also enables NCQ Trims on > > > ada SSDs. There are a few rogue drives that claim support for this > > > feature, but actually implement data corrupt instead of queued > > > trims. The list of known rogues is believed to be complete, but > > > some caution is in order. > > > > > > Warner > > > > Hi. > > Thanks for you work. > > But i have problem with VirtualBox if i use the kernel with option > > CAM_NETFLIX_IOSCHED > > http://imgur.com/JpcfW1h > > This problem is not over. > After the update on other hardware from r296979 to r298512 (!!! without > option CAM_NETFLIX_IOSCHED !!!) due to errors in recording the virtual > machine to a virtual disk I lost completely virtual machine with > permanent damage to the integrity of the file system in the inside of > the virtual machine. > > This is a serious bug! > > Who cares not to fall into the same situation - is testing yourself > and needed more testers. > Because there is a suspicion that the problem is also relevant for > bhyve VM. > With me on this no more neither the strength nor the desire nor > time. > > Thanks. > ___ freebsd-virtualization@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
Re: Heads up
On Fri, 15 Apr 2016 11:44:43 +0300 Ivan Klymenko wrote: > On Thu, 14 Apr 2016 16:42:33 -0600 > Warner Losh wrote: > > > The CAM I/O scheduler has been committed to current. This work is > > described in > > https://people.freebsd.org/~imp/bsdcan2015/iosched-v3.pdf though the > > default scheduler doesn't change the default (old) behavior. > > > > One possible issue, however, is that it also enables NCQ Trims on > > ada SSDs. There are a few rogue drives that claim support for this > > feature, but actually implement data corrupt instead of queued > > trims. The list of known rogues is believed to be complete, but > > some caution is in order. > > > > Warner > > Hi. > Thanks for you work. > But i have problem with VirtualBox if i use the kernel with option > CAM_NETFLIX_IOSCHED > http://imgur.com/JpcfW1h This problem is not over. After the update on other hardware from r296979 to r298512 (!!! without option CAM_NETFLIX_IOSCHED !!!) due to errors in recording the virtual machine to a virtual disk I lost completely virtual machine with permanent damage to the integrity of the file system in the inside of the virtual machine. This is a serious bug! Who cares not to fall into the same situation - is testing yourself and needed more testers. Because there is a suspicion that the problem is also relevant for bhyve VM. With me on this no more neither the strength nor the desire nor time. Thanks. ___ freebsd-virtualization@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
Re: HEADS UP: PCI SR-IOV infrastructure has been committed to head
On 2/28/15 6:01 PM, Ryan Stone wrote: I've just finished committing support for PCI Single Root I/O Virtualization in the pci subsystem to head. This should be a no-op for everyone right now, but there were some minor refactorings in the pci code that could have a lingering bug. I did make sure to test that it boots on a variety of systems (but only i386/amd64, as that's all that I have access to). awesome - this is great stuff! i'm looking forward to testing this when more driver vendors get sync'd up with this code (specifically solarflare). in lieu of working drivers is there any other testing that can be done now? 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"
Re: HEADS UP: Merging projects/bhyve_svm to HEAD
On Oct 26, 2014, at 4:40 PM, Zaphod Beeblebrox wrote: > On Sat, Oct 25, 2014 at 8:20 PM, Neel Natu wrote: > >> On Sat, Oct 25, 2014 at 3:50 PM, Zaphod Beeblebrox >> wrote: >>> I tried to integrate this patch into 10.1_RC3 and I failed. Is there a >>> timeframe to MFC this to 10.1 or 10-STABLE? >> >> It will be MFCed to 10-STABLE but I don't have a specific time frame in >> mind. >> >> I'll guess that it'll be towards the end of November but can be >> accelerated if someone has a need for this in 10-STABLE sooner. > > I would be using such a patch as soon as it was available. On a friend's > advice, I upgraded a ZFS server here at home with an AMD 9590 and 32Gig of > RAM. I'd dearly like to use it to track down the netgraph bug (see my > other recent posts), but it doesn't currently qualify. Ping? I'm also waiting with bated breath for this to be MFCed. :) Thanks for the great work! JN ___ 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: HEADS UP: Merging projects/bhyve_svm to HEAD
I would be using such a patch as soon as it was available. On a friend's advice, I upgraded a ZFS server here at home with an AMD 9590 and 32Gig of RAM. I'd dearly like to use it to track down the netgraph bug (see my other recent posts), but it doesn't currently qualify. On Sat, Oct 25, 2014 at 8:20 PM, Neel Natu wrote: > Hi, > > On Sat, Oct 25, 2014 at 3:50 PM, Zaphod Beeblebrox > wrote: > > I tried to integrate this patch into 10.1_RC3 and I failed. Is there a > > timeframe to MFC this to 10.1 or 10-STABLE? > > > > It will be MFCed to 10-STABLE but I don't have a specific time frame in > mind. > > I'll guess that it'll be towards the end of November but can be > accelerated if someone has a need for this in 10-STABLE sooner. > > best > Neel > > > On Sun, Oct 19, 2014 at 4:04 PM, Benjamin Perrault < > ben.perra...@gmail.com> > > wrote: > >> > >> After a few days of extensive testing and abuse, i’ve run into no new > >> issues or unknowns what so ever. Everything that worked before still > works > >> now ( and a few bugs from fixed from HEAD ). > >> > >> Thus, I have gone ahead and pushed r273182 w/ Neel’s patch out to about > 80 > >> of the assorted AMD boxes in the production and dev pods that I care > for. If > >> end users see something, I’ll let you know, but I have a feeling they > won’t. > >> > >> Again - Excellent work. > >> > >> cheers, > >> -bp > >> > >> > On Oct 19, 2014, at 5:03 AM, Willem Jan Withagen > >> > wrote: > >> > > >> > On 16-10-2014 5:00, Anish Gupta wrote: > >> >> Hi all, > >> >> > >> >> The projects/bhyve_svm branch is ready to be merged to HEAD. > >> >> > >> >> This branch contains patches to bhyve to enable it to work on AMD > >> >> processors with SVM/AMD-V hardware extensions[1]. Pretty much any AMD > >> >> processor since 2010 will have the features required by bhyve. > >> >> > >> >> bhyve on AMD supports (almost) all the features available with Intel > >> >> [2]. All guest OSes supported on Intel are supported on AMD. All the > >> >> bhyve-related utilities function similarly on both Intel and AMD > >> >> platforms [3]. > >> >> > >> >> The patch against HEAD revision 273066 is available for review and > >> >> testing: > >> >> https://people.freebsd.org/~neel/bhyve/bhyve_svm.diff [Neel’s web > >> >> directory] > >> >> > >> >> [1]: http://en.wikipedia.org/wiki/X86_virtualization > >> >> [2]: bhyve doesn't support PCI passthru on AMD at this time > >> >> [3]: bhyvectl has grown some processor-specific options > >> > > >> > Fetched the patch and compiled. > >> > Now running: HEAD r273066M and I was able to throw at it all the tests > >> > and images that in the past works. And perhaps even better. > >> > > >> > Great work. > >> > --WjW > >> > > >> > > >> > ___ > >> > 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" > >> > >> ___ > >> freebsd-curr...@freebsd.org mailing list > >> http://lists.freebsd.org/mailman/listinfo/freebsd-current > >> To unsubscribe, send any mail to " > freebsd-current-unsubscr...@freebsd.org" > > > > > ___ 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: HEADS UP: Merging projects/bhyve_svm to HEAD
Hi, On Sat, Oct 25, 2014 at 3:50 PM, Zaphod Beeblebrox wrote: > I tried to integrate this patch into 10.1_RC3 and I failed. Is there a > timeframe to MFC this to 10.1 or 10-STABLE? > It will be MFCed to 10-STABLE but I don't have a specific time frame in mind. I'll guess that it'll be towards the end of November but can be accelerated if someone has a need for this in 10-STABLE sooner. best Neel > On Sun, Oct 19, 2014 at 4:04 PM, Benjamin Perrault > wrote: >> >> After a few days of extensive testing and abuse, i’ve run into no new >> issues or unknowns what so ever. Everything that worked before still works >> now ( and a few bugs from fixed from HEAD ). >> >> Thus, I have gone ahead and pushed r273182 w/ Neel’s patch out to about 80 >> of the assorted AMD boxes in the production and dev pods that I care for. If >> end users see something, I’ll let you know, but I have a feeling they won’t. >> >> Again - Excellent work. >> >> cheers, >> -bp >> >> > On Oct 19, 2014, at 5:03 AM, Willem Jan Withagen >> > wrote: >> > >> > On 16-10-2014 5:00, Anish Gupta wrote: >> >> Hi all, >> >> >> >> The projects/bhyve_svm branch is ready to be merged to HEAD. >> >> >> >> This branch contains patches to bhyve to enable it to work on AMD >> >> processors with SVM/AMD-V hardware extensions[1]. Pretty much any AMD >> >> processor since 2010 will have the features required by bhyve. >> >> >> >> bhyve on AMD supports (almost) all the features available with Intel >> >> [2]. All guest OSes supported on Intel are supported on AMD. All the >> >> bhyve-related utilities function similarly on both Intel and AMD >> >> platforms [3]. >> >> >> >> The patch against HEAD revision 273066 is available for review and >> >> testing: >> >> https://people.freebsd.org/~neel/bhyve/bhyve_svm.diff [Neel’s web >> >> directory] >> >> >> >> [1]: http://en.wikipedia.org/wiki/X86_virtualization >> >> [2]: bhyve doesn't support PCI passthru on AMD at this time >> >> [3]: bhyvectl has grown some processor-specific options >> > >> > Fetched the patch and compiled. >> > Now running: HEAD r273066M and I was able to throw at it all the tests >> > and images that in the past works. And perhaps even better. >> > >> > Great work. >> > --WjW >> > >> > >> > ___ >> > 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" >> >> ___ >> freebsd-curr...@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > > ___ 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: HEADS UP: Merging projects/bhyve_svm to HEAD
I tried to integrate this patch into 10.1_RC3 and I failed. Is there a timeframe to MFC this to 10.1 or 10-STABLE? On Sun, Oct 19, 2014 at 4:04 PM, Benjamin Perrault wrote: > After a few days of extensive testing and abuse, i’ve run into no new > issues or unknowns what so ever. Everything that worked before still works > now ( and a few bugs from fixed from HEAD ). > > Thus, I have gone ahead and pushed r273182 w/ Neel’s patch out to about 80 > of the assorted AMD boxes in the production and dev pods that I care for. > If end users see something, I’ll let you know, but I have a feeling they > won’t. > > Again - Excellent work. > > cheers, > -bp > > > On Oct 19, 2014, at 5:03 AM, Willem Jan Withagen > wrote: > > > > On 16-10-2014 5:00, Anish Gupta wrote: > >> Hi all, > >> > >> The projects/bhyve_svm branch is ready to be merged to HEAD. > >> > >> This branch contains patches to bhyve to enable it to work on AMD > >> processors with SVM/AMD-V hardware extensions[1]. Pretty much any AMD > >> processor since 2010 will have the features required by bhyve. > >> > >> bhyve on AMD supports (almost) all the features available with Intel > >> [2]. All guest OSes supported on Intel are supported on AMD. All the > >> bhyve-related utilities function similarly on both Intel and AMD > >> platforms [3]. > >> > >> The patch against HEAD revision 273066 is available for review and > testing: > >> https://people.freebsd.org/~neel/bhyve/bhyve_svm.diff [Neel’s web > directory] > >> > >> [1]: http://en.wikipedia.org/wiki/X86_virtualization > >> [2]: bhyve doesn't support PCI passthru on AMD at this time > >> [3]: bhyvectl has grown some processor-specific options > > > > Fetched the patch and compiled. > > Now running: HEAD r273066M and I was able to throw at it all the tests > > and images that in the past works. And perhaps even better. > > > > Great work. > > --WjW > > > > > > ___ > > 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" > > ___ > freebsd-curr...@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > ___ 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: HEADS UP: Merging projects/bhyve_svm to HEAD
After a few days of extensive testing and abuse, i’ve run into no new issues or unknowns what so ever. Everything that worked before still works now ( and a few bugs from fixed from HEAD ). Thus, I have gone ahead and pushed r273182 w/ Neel’s patch out to about 80 of the assorted AMD boxes in the production and dev pods that I care for. If end users see something, I’ll let you know, but I have a feeling they won’t. Again - Excellent work. cheers, -bp > On Oct 19, 2014, at 5:03 AM, Willem Jan Withagen wrote: > > On 16-10-2014 5:00, Anish Gupta wrote: >> Hi all, >> >> The projects/bhyve_svm branch is ready to be merged to HEAD. >> >> This branch contains patches to bhyve to enable it to work on AMD >> processors with SVM/AMD-V hardware extensions[1]. Pretty much any AMD >> processor since 2010 will have the features required by bhyve. >> >> bhyve on AMD supports (almost) all the features available with Intel >> [2]. All guest OSes supported on Intel are supported on AMD. All the >> bhyve-related utilities function similarly on both Intel and AMD >> platforms [3]. >> >> The patch against HEAD revision 273066 is available for review and testing: >> https://people.freebsd.org/~neel/bhyve/bhyve_svm.diff [Neel’s web directory] >> >> [1]: http://en.wikipedia.org/wiki/X86_virtualization >> [2]: bhyve doesn't support PCI passthru on AMD at this time >> [3]: bhyvectl has grown some processor-specific options > > Fetched the patch and compiled. > Now running: HEAD r273066M and I was able to throw at it all the tests > and images that in the past works. And perhaps even better. > > Great work. > --WjW > > > ___ > 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" ___ 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: HEADS UP: Merging projects/bhyve_svm to HEAD
On 16-10-2014 5:00, Anish Gupta wrote: > Hi all, > > The projects/bhyve_svm branch is ready to be merged to HEAD. > > This branch contains patches to bhyve to enable it to work on AMD > processors with SVM/AMD-V hardware extensions[1]. Pretty much any AMD > processor since 2010 will have the features required by bhyve. > > bhyve on AMD supports (almost) all the features available with Intel > [2]. All guest OSes supported on Intel are supported on AMD. All the > bhyve-related utilities function similarly on both Intel and AMD > platforms [3]. > > The patch against HEAD revision 273066 is available for review and testing: > https://people.freebsd.org/~neel/bhyve/bhyve_svm.diff [Neel’s web directory] > > [1]: http://en.wikipedia.org/wiki/X86_virtualization > [2]: bhyve doesn't support PCI passthru on AMD at this time > [3]: bhyvectl has grown some processor-specific options Fetched the patch and compiled. Now running: HEAD r273066M and I was able to throw at it all the tests and images that in the past works. And perhaps even better. Great work. --WjW ___ 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: HEADS UP: Merging projects/bhyve_svm to HEAD
I’ve applied Neel’s patch against r273182 and am currently abusively testing it on a mix of HP DL385s w/ dual Opteron 6378SE, & Single socket AMD G34s ( some with Opteron 6200s, some with 6300s ), about 15 boxes in total - so far so good. Seriously awesome work Gentlemen. cheers, -bp > On Oct 15, 2014, at 8:30 PM, Matthew Grooms wrote: > > Fantastic news! Greatly appreciated. > > -Matthew > > On Oct 15, 2014 10:00 PM, Anish Gupta wrote: >> >> Hi all, >> >> The projects/bhyve_svm branch is ready to be merged to HEAD. >> >> This branch contains patches to bhyve to enable it to work on AMD >> processors with SVM/AMD-V hardware extensions[1]. Pretty much any AMD >> processor since 2010 will have the features required by bhyve. >> >> bhyve on AMD supports (almost) all the features available with Intel >> [2]. All guest OSes supported on Intel are supported on AMD. All the >> bhyve-related utilities function similarly on both Intel and AMD >> platforms [3]. >> >> The patch against HEAD revision 273066 is available for review and testing: >> https://people.freebsd.org/~neel/bhyve/bhyve_svm.diff [Neel’s web directory] >> >> [1]: http://en.wikipedia.org/wiki/X86_virtualization >> [2]: bhyve doesn't support PCI passthru on AMD at this time >> [3]: bhyvectl has grown some processor-specific options >> >> Thanks and regards, >> Peter, Neel & Anish[akgu...@gmail.com] >> ___ >> 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" > ___ > 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" ___ 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: HEADS UP: Merging projects/bhyve_svm to HEAD
Fantastic news! Greatly appreciated. -Matthew On Oct 15, 2014 10:00 PM, Anish Gupta wrote: > > Hi all, > > The projects/bhyve_svm branch is ready to be merged to HEAD. > > This branch contains patches to bhyve to enable it to work on AMD > processors with SVM/AMD-V hardware extensions[1]. Pretty much any AMD > processor since 2010 will have the features required by bhyve. > > bhyve on AMD supports (almost) all the features available with Intel > [2]. All guest OSes supported on Intel are supported on AMD. All the > bhyve-related utilities function similarly on both Intel and AMD > platforms [3]. > > The patch against HEAD revision 273066 is available for review and testing: > https://people.freebsd.org/~neel/bhyve/bhyve_svm.diff [Neel’s web directory] > > [1]: http://en.wikipedia.org/wiki/X86_virtualization > [2]: bhyve doesn't support PCI passthru on AMD at this time > [3]: bhyvectl has grown some processor-specific options > > Thanks and regards, > Peter, Neel & Anish[akgu...@gmail.com] > ___ > 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" ___ 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: HEADS UP: Merging projects/bhyve_svm to HEAD
On 2014-10-15 23:00, Anish Gupta wrote: > Hi all, > > The projects/bhyve_svm branch is ready to be merged to HEAD. > > This branch contains patches to bhyve to enable it to work on AMD > processors with SVM/AMD-V hardware extensions[1]. Pretty much any AMD > processor since 2010 will have the features required by bhyve. > > bhyve on AMD supports (almost) all the features available with Intel > [2]. All guest OSes supported on Intel are supported on AMD. All the > bhyve-related utilities function similarly on both Intel and AMD > platforms [3]. > > The patch against HEAD revision 273066 is available for review and testing: > https://people.freebsd.org/~neel/bhyve/bhyve_svm.diff [Neel’s web directory] > > [1]: http://en.wikipedia.org/wiki/X86_virtualization > [2]: bhyve doesn't support PCI passthru on AMD at this time > [3]: bhyvectl has grown some processor-specific options > > Thanks and regards, > Peter, Neel & Anish[akgu...@gmail.com] > ___ > 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" > Great work guys. I know many people are looking forward to this -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: HEADS UP: tenetative plan to merge VIMAGE parts
On Tue, 15 Feb 2011, Mikolaj Golub wrote: Hi, I did not do much testing but the patch works for me. Thanks! Committed to HEAD as r218757. BAZ> I'd suggest we'll check an updated smbfs patch after that and get it BAZ> in (if still needed). Previously I patched smb_trantcp.c in order to prevent crashes when mounting smbfs. Now it looks likes I don't need it any more -- smb works without that patch. Cool; that's what I was hoping for. Another item crossed off:) /bz -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. ___ 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: HEADS UP: tenetative plan to merge VIMAGE parts
On Sun, 13 Feb 2011 17:01:28 + (UTC) Bjoern A. Zeeb wrote: BAZ> On Thu, 3 Feb 2011, Bjoern A. Zeeb wrote: BAZ> Hi, >> next week I plan to extract the initial parts from perforce and merge >> them to SVN. This will include: >> >> 1) vnet socket pushdown. BAZ> As some might have noticed I committed a bit of the "noise" from that BAZ> already. It's proven kind of hard to extract the things from perforce BAZ> with an additional several months of development and changes on top, BAZ> but it'll be easier with every commit to SVN;) BAZ> I will continue to directly commit small changes to SVN while I will BAZ> post larger ones here for review/testing. If you are tracking VIMAGE BAZ> in HEAD and anything breaks for you please yell at me! BAZ> Here's the vnet socket push back patch: BAZ> http://people.freebsd.org/~bz/20110213-01-vnet-socket-pushdown.diff BAZ> I have done some but not thorough testing on the patch. Given it BAZ> should be a complete extract from p4 I have been using it for more BAZ> than half a year though;) BAZ> I plan to commit this early-mid-weekish, so if you want to test let me BAZ> know by then. I did not do much testing but the patch works for me. BAZ> If you are on stable/8 you might want to apply the combined upcoming BAZ> merge patch before the above: BAZ> http://people.freebsd.org/~bz/20110213-02-vnet-mfc01.diff Running my notebook (stable/8) with these patches. BAZ> I'd suggest we'll check an updated smbfs patch after that and get it BAZ> in (if still needed). Previously I patched smb_trantcp.c in order to prevent crashes when mounting smbfs. Now it looks likes I don't need it any more -- smb works without that patch. -- Mikolaj Golub ___ 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: HEADS UP: tenetative plan to merge VIMAGE parts
On Thu, 3 Feb 2011, Bjoern A. Zeeb wrote: Hi, next week I plan to extract the initial parts from perforce and merge them to SVN. This will include: 1) vnet socket pushdown. As some might have noticed I committed a bit of the "noise" from that already. It's proven kind of hard to extract the things from perforce with an additional several months of development and changes on top, but it'll be easier with every commit to SVN;) I will continue to directly commit small changes to SVN while I will post larger ones here for review/testing. If you are tracking VIMAGE in HEAD and anything breaks for you please yell at me! Here's the vnet socket push back patch: http://people.freebsd.org/~bz/20110213-01-vnet-socket-pushdown.diff I have done some but not thorough testing on the patch. Given it should be a complete extract from p4 I have been using it for more than half a year though;) I plan to commit this early-mid-weekish, so if you want to test let me know by then. If you are on stable/8 you might want to apply the combined upcoming merge patch before the above: http://people.freebsd.org/~bz/20110213-02-vnet-mfc01.diff I'd suggest we'll check an updated smbfs patch after that and get it in (if still needed). Regards, Bjoern -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. ___ 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: HEADS UP: tenetative plan to merge VIMAGE parts
On 2/3/11 11:47 AM, Bjoern A. Zeeb wrote: Hi, I will be at FOSDEM this weekend (if you are as well and want to talk, send me an email off list or try to find me in the crowds). When back next week I plan to extract the initial parts from perforce and merge them to SVN. This will include: 1) vnet socket pushdown. followed by: 2) general VIMAGE framework. and 3) user space changes. probably along with some "noise" to ddb and documentation. it could be that VIMAGE in HEAD would be "unstable" for a couple of days during these times. the sooner the better I think This batch will not yet include actual VNET teardwn or interface cloners changes but will provide the foundation for that. I hope I'll be able to quickly afterwards make the patches for the interface cloners available and in addition to the bridge code posted and the carp code I have, so we can look at the missing cloned interfaces state, while in parallel trying to get ports breakage figured out. I'll keep you updated during next week as things progress and might post merge candidate patches for your testing. Regards, Bjoern ___ 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: HEADS UP: r185435 multi-IPv4/v6/no-IP jails in HEAD
On Mon, 15 Dec 2008, Brian A. Seklecki wrote: On Thu, 2008-12-11 at 22:53 +0100, Philipp Wuensche wrote: Not entirely true, the jls output is totaly different than before and breaks third-party applications like jailaudit and ezjail. Right, well, whether they check for VERSION > 70200x or 8, the format will is likely to change. Once everything has been sorted out, they can add support now, push out the updates, and the version in common use will be forward/backward compatible. Whatever we have to do to light a fire there -- I just don't want ezjail-admin compatibility to be a showstopper on this. Two comments: the format as is, is most likely to stay for the livetime of the 7.x branch once things are MFCed. For 8 with vimage and we'll get an entirely new management interface for all this. /bz PS: yes, I know rc.d/jail foo still needs integration. Has anyone tested what was posted? -- Bjoern A. Zeeb The greatest risk is not taking one. ___ 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: HEADS UP: r185435 multi-IPv4/v6/no-IP jails in HEAD
On Thu, 2008-12-11 at 22:53 +0100, Philipp Wuensche wrote: > Not entirely true, the jls output is totaly different than before and > breaks third-party applications like jailaudit and ezjail. Right, well, whether they check for VERSION > 70200x or 8, the format will is likely to change. Once everything has been sorted out, they can add support now, push out the updates, and the version in common use will be forward/backward compatible. Whatever we have to do to light a fire there -- I just don't want ezjail-admin compatibility to be a showstopper on this. > > It is uneasy to parse too. -- Brian A. Seklecki Collaborative Fusion, Inc. signature.asc Description: This is a digitally signed message part
Re: HEADS UP: vimage - virtualized global variables in the network stack
From: Max Laier Subject: Re: HEADS UP: vimage - virtualized global variables in the network stack Date: Sat, 13 Dec 2008 20:45:16 +0100 > On Saturday 13 December 2008 20:33:53 Bjoern A. Zeeb wrote: > ... > > This state of having the variables in parallel, global and in the > > container struct, will be maintained for another (short) time until > > the entire virtualization framework is in. This is needed, so that > > all three possible states can be benchmarked from exactly the same > > code changeset. > > > > > > For developers comitting new code or changing code it is important to > > properly add virtualized variables in the way that: > > 1) the globals and externs (if needed) are added/kept in sync as both > > a) globals under #ifdef VIMAGE_GLOBALS and b) to the appropriate > > container struct + the V_ macro. > > When used somewhere in code one has to use the V_foobarbaz version. > > Is there (an easy) way to have the tinderbox build every other run without > VIMAGE_GLOBALS so that the most obvious error (global available, but not in > the container struct - or the other way around) can be warned about? This actually points out why the 'tinderbox' name is bogus for the universe plus failure: universe builds all the kernels. Tinderbox builds LINT only. Warner ___ 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: HEADS UP: vimage - virtualized global variables in the network stack
On Sat, 13 Dec 2008, Max Laier wrote: On Saturday 13 December 2008 20:33:53 Bjoern A. Zeeb wrote: ... This state of having the variables in parallel, global and in the container struct, will be maintained for another (short) time until the entire virtualization framework is in. This is needed, so that all three possible states can be benchmarked from exactly the same code changeset. For developers comitting new code or changing code it is important to properly add virtualized variables in the way that: 1) the globals and externs (if needed) are added/kept in sync as both a) globals under #ifdef VIMAGE_GLOBALS and b) to the appropriate container struct + the V_ macro. When used somewhere in code one has to use the V_foobarbaz version. Is there (an easy) way to have the tinderbox build every other run without VIMAGE_GLOBALS so that the most obvious error (global available, but not in the container struct - or the other way around) can be warned about? Without VIMAGE_GLOBALS is the default; we have been building this for a few days already. The flip had been so smoothly that almost noone had really noticed. Marko has done a really great job! Thus my HEADS UP now after I am confident enough that (almost) all places were caught and clean. In case you want to check yourself you can simply put a file into one or multiple archs conf dir that looks like: cat sys/amd64/conf/LINT-VIMAGE_GLOBALS include LINT ident LINT-VIMAGE_GLOBALS options VIMAGE_GLOBALS I am doing that build every other day from now to catch the possible error of a virtualized variable in the container struct w/o the global. But as this is the least problematic case I do not want to commit the kernel configuration as it'll make builds longer for everyone, etc. The more problematic cases that builds cannot catch are: - static initialization of a virtualized 'global'. - a newly added virtualized 'global' that is not under #ifdef VIMAGE_GLOBALS I have scripts to identify the latter already. The former will only be caught be either code inspection or "unexpected results" when running. /bz -- Bjoern A. Zeeb The greatest risk is not taking one. ___ 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: HEADS UP: vimage - virtualized global variables in the network stack
On Saturday 13 December 2008 20:33:53 Bjoern A. Zeeb wrote: ... > This state of having the variables in parallel, global and in the > container struct, will be maintained for another (short) time until > the entire virtualization framework is in. This is needed, so that > all three possible states can be benchmarked from exactly the same > code changeset. > > > For developers comitting new code or changing code it is important to > properly add virtualized variables in the way that: > 1) the globals and externs (if needed) are added/kept in sync as both > a) globals under #ifdef VIMAGE_GLOBALS and b) to the appropriate > container struct + the V_ macro. > When used somewhere in code one has to use the V_foobarbaz version. Is there (an easy) way to have the tinderbox build every other run without VIMAGE_GLOBALS so that the most obvious error (global available, but not in the container struct - or the other way around) can be warned about? -- /"\ Best regards, | mla...@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mla...@efnet / \ ASCII Ribbon Campaign | Against HTML Mail and News ___ 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: HEADS UP: r185435 multi-IPv4/v6/no-IP jails in HEAD
Brian A. Seklecki wrote: > On Fri, 2008-12-05 at 20:47 +0100, Dag-Erling Smørgrav wrote: >> The question is, does it change existing behavior, or just add new >> functionality? > > The syntax semantics should be backward compatible, so likely the > latter. Not entirely true, the jls output is totaly different than before and breaks third-party applications like jailaudit and ezjail. It is uneasy to parse too. greetings, Philipp ___ 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: HEADS UP: r185435 multi-IPv4/v6/no-IP jails in HEAD
Philipp Wuensche writes: > Not entirely true, the jls output is totaly different than before and > breaks third-party applications like jailaudit and ezjail. > > It is uneasy to parse too. jls | tail +3 | while read line ; do set $line if [ $# = 3 ] ; then echo "jail $1 (name $2 root $3) IPs:" elif [ $# = 1 ] ; then echo "$1" else echo "huh?" fi done DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: HEADS UP: r185435 multi-IPv4/v6/no-IP jails in HEAD
On Fri, 2008-12-05 at 20:47 +0100, Dag-Erling Smørgrav wrote: > The question is, does it change existing behavior, or just add new > functionality? The syntax semantics should be backward compatible, so likely the latter. -- Brian A. Seklecki <[EMAIL PROTECTED]> Collaborative Fusion, Inc. signature.asc Description: This is a digitally signed message part
Re: HEADS UP: r185435 multi-IPv4/v6/no-IP jails in HEAD
"Brian A. Seklecki" <[EMAIL PROTECTED]> writes: > alexus <[EMAIL PROTECTED]> writes: > > as far as I understood HEAD is 8.0-CURRENT > The trick is to bribe the right people to get it RFP'd into 7.2R. :) The question is, does it change existing behavior, or just add new functionality? If the former, it should not be MFCed. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: r185435 multi-IPv4/v6/no-IP jails in HEAD
On Tue, 2008-12-02 at 21:00 -0500, alexus wrote: > as far as I understood HEAD is 8.0-CURRENT The trick is to bribe the right people to get it RFP'd into 7.2R. :) ~BAS -- Brian A. Seklecki <[EMAIL PROTECTED]> Collaborative Fusion, Inc. signature.asc Description: This is a digitally signed message part
Re: HEADS UP: r185435 multi-IPv4/v6/no-IP jails in HEAD
as far as I understood HEAD is 8.0-CURRENT is there a way for us to start using it before 8.0 hits -RELEASE which according to freebsd.org will be in june 2009, which we all know how accured their schedule is, so, my guess is very well Q4 of 2009 (if we lucky), I somehow was under impression (and i guess i was wrong) that it will come out in 7.1, I have a server that needs to be migrated and really doing so without multi ip patch will be a really big . -- http://alexus.org/ ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: r185435 multi-IPv4/v6/no-IP jails in HEAD
Quoting "Bjoern A. Zeeb" <[EMAIL PROTECTED]> (from Mon, 1 Dec 2008 09:41:46 + (UTC)): Hi, as you may have already noticed multi-IPv4/v6/no-IP jails have hit HEAD. See commit message attached. Will this introduce changes how multicast is handled in jails, or is it the same behavior as before (whatever the previous behavior was). Additionally you can give a jail a name now using the -n option: jail -n "bz's private noip jail" / noip.example.net "" /bin/sh You may not want to use special characters or whitespace but it is just a string, so you can. There are no restrictions and even 10 jails could have the same name. The jail (inside) cannot change the name. It's set upon jail creation and unchangeable from then on. Is this private name visible inside the jail (I don't need this feature, so I don't care, but people should know so that they don't put offensive stuff there in case it is visible inside)? Bye, Alexander. -- Since we cannot hope for order, let us withdraw with style from the chaos. -- Tom Stoppard http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "[EMAIL PROTECTED]"
