Another vmd sanity check recommendation / WAS: "vmctl stop" causing disk image corruption with OpenBSD 6.2-stable VM
Hi Mike, I got curious again and tried starting a second vmd process when there is already a running vmd process. The new process causes the original process to stop responding. As expected, this makes a mess of the disk image files already loaded by the first vmd process. I also tried starting the second vmd process using a distinct vm.conf which used none of the disk image files from the original vmd process. This still causes the VMs running under the first vmd process to stop responding, even after the second vmd process is killed. The disk image files from the original process were also flagged for fsck at reboot of the VMs. Perhaps another sanity check for the to-do list... don't start vmd if it is already running? Yours truly, Breen From: Mike Larkin <mlar...@azathoth.net> Sent: February 3, 2018 4:49 PM To: openbsd2012 Cc: 'misc@openbsd.org' Subject: Re: "vmctl stop" causing disk image corruption with OpenBSD 6.2-stable VM ... > May I suggest a vmd sanity check to avoid a VM disk image being loaded by > more than one VM simultaneously? Providing a patch is outside my skill set, > unfortunately. > > > Yours truly, > > > Breen > Not a bad idea, I'll toss it on the to-do list. thanks.. -ml
Re: "vmctl stop" causing disk image corruption with OpenBSD 6.2-stable VM
Hi Mike, Before receiving your reply, I reinstalled the vmd host using the latest snapshot. I built everything up from scratch and did not encounter the problem further. However, I had a nagging thought this morning: did I accidentally start a second VM using the disk image file from another running VM? I tested using a VM image file simultaneously on two VMs. It works, in that both VMs boot. Predictably, rebooting one of them produces the same corruption and boot looping I saw previously. I was surprised that vmd would allow the action rather than throw an error. May I suggest a vmd sanity check to avoid a VM disk image being loaded by more than one VM simultaneously? Providing a patch is outside my skill set, unfortunately. Yours truly, Breen From: Mike Larkin <mlar...@azathoth.net> Sent: February 1, 2018 10:21 PM To: openbsd2012 Cc: misc@openbsd.org Subject: Re: "vmctl stop" causing disk image corruption with OpenBSD 6.2-stable VM On Fri, Feb 02, 2018 at 05:36:16AM +0000, openbsd2012 wrote: > I've been testing out vmd with a single OpenBSD VM for about a week. > > > Running "vmctl stop 1" from the vmd host often causes the VM on reboot to > output "WARNING: / was not properly unmounted", or in some cases the VM will > loop infinitely at the boot prompt. > > > I can avoid disk image corruption by first halting within the VM then issuing > "vmctl stop 1" from the vmd host. However, the man page for vmctl leads me to > believe that only "vmctl stop 1" should be necessary for a graceful shutdown > of the VM. > > > If I halt from an OpenSSH session, but monitor the VM on its console, the VM > stops just after the output: > > > login: syncing disks... done > vmmci0: powerdown > > The operating system has halted. > Please press any key to reboot. > > > However, if I run "vmctl stop 1" from the vmd host, while monitoring the VM > on its console, the VM stops without any output. More often than not, the > disk image is then corrupted on reboot. > > > Have I misunderstood the manual for vmctl? Should the VM shutdown gracefully > on the issue of the "vmctl stop 1" command? > > > The vmd host is running a recent snapshot, while the VM is running 6.2-stable > (although I found the same problem while also using the same snapshot in the > VM). > > Thanks. > vmctl stop X sends a request to the VM to terminate. That's done via vmmci(4). If vmd doesn't get a reply within 60s, it forcibly terminates the VM. That's the same thing you see above (vmmci0: powerdown). Please remain connected to the console while doing vmctl stop X and tell me what it says. Does it shutdown properly or just hang or spontaneously reboot? -ml > > dmesg from vmd host: > > > OpenBSD 6.2-current (GENERIC.MP) #387: Wed Jan 24 12:53:55 MST 2018 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 68594307072 (65416MB) > avail mem = 66508513280 (63427MB) > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xed9b0 (39 entries) > bios0: vendor American Megatrends Inc. version "1.1b" date 07/13/2016 > bios0: Supermicro Super Server > acpi0 at bios0: rev 2 > acpi0: sleep states S0 S4 S5 > acpi0: tables DSDT FACP APIC FPDT FIDT SPMI MCFG UEFI DBG2 HPET WDDT SSDT > SSDT SSDT PRAD DMAR HEST BERT ERST EINJ > acpi0: wakeup devices IP2P(S4) XHCI(S4) EHC1(S4) EHC2(S4) RP01(S4) RP02(S4) > RP03(S4) RP04(S4) RP05(S4) RP06(S4) RP07(S4) RP08(S4) BR1A(S4) BR1B(S4) > BR2A(S4) BR2B(S4) [...] > acpitimer0 at acpi0: 3579545 Hz, 24 bits > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: Intel(R) Xeon(R) CPU D-1541 @ 2.10GHz, 2100.30 MHz > cpu0: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,PQM,RDSEED,ADX,SMAP,PT,SENSOR,ARAT > cpu0: 256KB 64b/line 8-way L2 cache > acpitimer0: recalibrated TSC frequency 208920 Hz > cpu0: smt 0, core 0, package 0 > mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges > cpu0: apic clock running at 99MHz > cpu0: mwait min=64, max=64, C-substates=0.2.1.2, IBE > cpu1 at mainbus0: apid 2 (application processor) > cpu1: Intel(R) Xeon(R) CPU D-1541 @ 2.10GHz, 2100.00 MHz > cpu1: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH
"vmctl stop" causing disk image corruption with OpenBSD 6.2-stable VM
I've been testing out vmd with a single OpenBSD VM for about a week. Running "vmctl stop 1" from the vmd host often causes the VM on reboot to output "WARNING: / was not properly unmounted", or in some cases the VM will loop infinitely at the boot prompt. I can avoid disk image corruption by first halting within the VM then issuing "vmctl stop 1" from the vmd host. However, the man page for vmctl leads me to believe that only "vmctl stop 1" should be necessary for a graceful shutdown of the VM. If I halt from an OpenSSH session, but monitor the VM on its console, the VM stops just after the output: login: syncing disks... done vmmci0: powerdown The operating system has halted. Please press any key to reboot. However, if I run "vmctl stop 1" from the vmd host, while monitoring the VM on its console, the VM stops without any output. More often than not, the disk image is then corrupted on reboot. Have I misunderstood the manual for vmctl? Should the VM shutdown gracefully on the issue of the "vmctl stop 1" command? The vmd host is running a recent snapshot, while the VM is running 6.2-stable (although I found the same problem while also using the same snapshot in the VM). Thanks. dmesg from vmd host: OpenBSD 6.2-current (GENERIC.MP) #387: Wed Jan 24 12:53:55 MST 2018 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 68594307072 (65416MB) avail mem = 66508513280 (63427MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xed9b0 (39 entries) bios0: vendor American Megatrends Inc. version "1.1b" date 07/13/2016 bios0: Supermicro Super Server acpi0 at bios0: rev 2 acpi0: sleep states S0 S4 S5 acpi0: tables DSDT FACP APIC FPDT FIDT SPMI MCFG UEFI DBG2 HPET WDDT SSDT SSDT SSDT PRAD DMAR HEST BERT ERST EINJ acpi0: wakeup devices IP2P(S4) XHCI(S4) EHC1(S4) EHC2(S4) RP01(S4) RP02(S4) RP03(S4) RP04(S4) RP05(S4) RP06(S4) RP07(S4) RP08(S4) BR1A(S4) BR1B(S4) BR2A(S4) BR2B(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Xeon(R) CPU D-1541 @ 2.10GHz, 2100.30 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,PQM,RDSEED,ADX,SMAP,PT,SENSOR,ARAT cpu0: 256KB 64b/line 8-way L2 cache acpitimer0: recalibrated TSC frequency 208920 Hz cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Xeon(R) CPU D-1541 @ 2.10GHz, 2100.00 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,PQM,RDSEED,ADX,SMAP,PT,SENSOR,ARAT cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Xeon(R) CPU D-1541 @ 2.10GHz, 2100.00 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,PQM,RDSEED,ADX,SMAP,PT,SENSOR,ARAT cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 6 (application processor) cpu3: Intel(R) Xeon(R) CPU D-1541 @ 2.10GHz, 2100.00 MHz cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,PQM,RDSEED,ADX,SMAP,PT,SENSOR,ARAT cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 0, core 3, package 0 cpu4 at mainbus0: apid 8 (application processor) cpu4: Intel(R) Xeon(R) CPU D-1541 @ 2.10GHz, 2100.00 MHz cpu4:
Installed 5.7/amd64, now No acceptable DHCPOFFERS received.
I decided that tonight was the time to upgrade my home router from OpenBSD 5.2/amd64. I performed a new install of 5.7/amd64. During the install, a DHCP lease could not be obtained on em0 from my ISP. On first boot it gave me No acceptable DHCPOFFERS received. I flashed the latest BIOS and received the same error on boot. This computer has a Supermicro X7SPA-HF mainboard (an Intel Atom CPU with two onboard Intel gigabit NICs). In addition to the dhclient problem, I've also noticed that the onboard Matrox G200 video no longer works with X. No idea if these problems are related. None of the 5.7 errata appear to be applicable, but I'll patch them up tomorrow just in case. I thought that I had better post this tonight, because I'm essentially at the end of my rope. Thanks, dmesg follows: OpenBSD 5.7 (GENERIC.MP) #881: Sun Mar 8 11:04:17 MDT 2015 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 2130182144 (2031MB) avail mem = 2069618688 (1973MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.6 @ 0x9f000 (19 entries) bios0: vendor American Megatrends Inc. version 1.2b date 07/19/13 bios0: Supermicro X7SPA-HF acpi0 at bios0: rev 2 acpi0: sleep states S0 S1 S4 S5 acpi0: tables DSDT FACP APIC MCFG OEMB HPET EINJ BERT ERST HEST acpi0: wakeup devices P0P1(S4) PS2K(S4) PS2M(S4) USB0(S4) USB1(S4) USB2(S4) USB5(S4) EUSB(S4) USB3(S4) USB4(S4) USB6(S4) USBE(S4) P0P4(S4) P0P5(S4) P0P6(S4) P0P7(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Atom(TM) CPU D510 @ 1.66GHz, 1666.91 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,TM2,SSSE3, CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF cpu0: 512KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 166MHz cpu0: mwait min=64, max=64, C-substates=0.1.0.0.0, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Atom(TM) CPU D510 @ 1.66GHz, 1666.67 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,TM2,SSSE3, CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF cpu1: 512KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 1 (application processor) cpu2: Intel(R) Atom(TM) CPU D510 @ 1.66GHz, 1666.67 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,TM2,SSSE3, CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF cpu2: 512KB 64b/line 8-way L2 cache cpu2: smt 1, core 0, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Atom(TM) CPU D510 @ 1.66GHz, 1666.67 MHz cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,TM2,SSSE3, CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF cpu3: 512KB 64b/line 8-way L2 cache cpu3: smt 1, core 1, package 0 ioapic0 at mainbus0: apid 4 pa 0xfec0, version 20, 24 pins ioapic0: misconfigured as apic 1, remapped to apid 4 acpimcfg0 at acpi0 addr 0xe000, bus 0-255 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 4 (P0P1) acpiprt2 at acpi0: bus 1 (P0P4) acpiprt3 at acpi0: bus 2 (P0P8) acpiprt4 at acpi0: bus 3 (P0P9) acpicpu0 at acpi0 acpicpu1 at acpi0 acpicpu2 at acpi0 acpicpu3 at acpi0 acpibtn0 at acpi0: SLPB acpibtn1 at acpi0: PWRB ipmi at mainbus0 not configured pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 Intel Pineview DMI rev 0x02 uhci0 at pci0 dev 26 function 0 Intel 82801I USB rev 0x02: apic 4 int 16 uhci1 at pci0 dev 26 function 1 Intel 82801I USB rev 0x02: apic 4 int 21 uhci2 at pci0 dev 26 function 2 Intel 82801I USB rev 0x02: apic 4 int 19 ehci0 at pci0 dev 26 function 7 Intel 82801I USB rev 0x02: apic 4 int 18 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 Intel EHCI root hub rev 2.00/1.00 addr 1 ppb0 at pci0 dev 28 function 0 Intel 82801I PCIE rev 0x02: msi pci1 at ppb0 bus 1 ppb1 at pci0 dev 28 function 4 Intel 82801I PCIE rev 0x02: msi pci2 at ppb1 bus 2 em0 at pci2 dev 0 function 0 Intel 82574L rev 0x00: msi, address 00:25:90:0a:3d:fc ppb2 at pci0 dev 28 function 5 Intel 82801I PCIE rev 0x02: msi pci3 at ppb2 bus 3 em1 at pci3 dev 0 function 0 Intel 82574L rev 0x00: msi, address 00:25:90:0a:3d:fd uhci3 at pci0 dev 29 function 0 Intel 82801I USB rev 0x02: apic 4 int 23 uhci4 at pci0 dev 29 function 1 Intel 82801I USB rev 0x02: apic 4 int 19 uhci5 at pci0 dev 29 function 2 Intel 82801I USB rev 0x02: apic 4 int 18 ehci1 at pci0 dev 29 function 7 Intel 82801I USB rev 0x02: apic 4 int 23 usb1 at ehci1: USB revision 2.0 uhub1 at usb1 Intel EHCI root hub rev 2.00/1.00 addr 1 ppb3 at
Re: Why are there no PKG_PATH defaults?
| -Original Message-
| From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On
| Behalf Of openda...@hushmail.com
| Sent: Tuesday, September 23, 2014 6:01 AM
| Subject: Why are there no PKG_PATH defaults?
...
| Expanding on the whole
| http://en.wikipedia.org/wiki/Convention_over_configuration thing -- why
| aren't there any sane PKG_PATH defaults? Ie.:
|
| release=$(uname -r)
| architecture=$(uname -p)
|
| export
| PKG_PATH=ftp://ftp.openbsd.org/pub/OpenBSD/${release}/packages/${arc
| hitecture}/
|
Because your sane default includes ftp.openbsd.org, which is not sane at all.
If PKG_PATH or /etc/pkg.conf were set to default to ftp.openbsd.org then that
host would get hammered instead of the user being put in the position of
choosing a local mirror.
-Breeno
PS - In anticipation of the typical follow-up argument, whether or not there is
a large existing base of lazy people who fail to choose a local mirror is not a
valid argument for defaulting all users to ftp.openbsd.org. Such reasoning
would merely exacerbate the trouble with the hypothetical status quo.
Re: PDF FAQ [Was: Donations to OpenBSD]
| I've seen this before. It has never helped OpenBSD. I'll stop short of calling | the OP a troll, but boy, what an amazing distraction. I wonder who funds | him. Yep, if it's such a great idea then why aren't these suggestion makers doing it? The answer is that it would be a colossal waste of their time. If they really believed in their suggestions then they would step up and really volunteer to make it happen. Instead, they try to foist it on the project developers. It's nothing more than wishful thinking at work. As the saying goes, wish in one hand, shit in the other, and see which one fills up first. Anyone who is really serious will just donate money without any expectation of getting something for it, because the smart ones among the user base already realize that the OpenBSD software releases are paying it back in spades. By next year I'll be finished articling, I'll be earning a real paycheque once more, and you can expect to start receiving those annual $200 cheques from me again, Theo. I'll wager that not one of these suggestion makers has even managed half that amount on a recurring basis. Maybe not even one tenth. I'm mean, didn't the one guy say he bought a t-shirt once? How generous of him. You better adopt every suggestion he makes. I mean, you owe him, right? :eyeroll: Breeno
Re: For Google+ users: BSD community
Also, the strictly OpenBSD community on G+: https://plus.google.com/communities/113634135604793474364 | -Original Message- | From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On | Behalf Of Tony Sidaway | Sent: Monday, November 18, 2013 6:18 AM | To: OpenBSD misc | Subject: For Google+ users: BSD community | | If you're using Google+, this community brings together all BSD systems and | BSD projects such as pf, OpenSSH and ZFS. I started it so I could keep in touch | with what's going on in other BSDs while I happily use OpenBSD, and that's | pretty much how it works out. | | It's spam-free and 100% on topic, and mostly consists of announcements and | links to news items from the different communities. OpenBSD is well | represented. | | https://plus.google.com/communities/100298923022265155991
Re: QEMU CPU cores not showing up
| -Original Message- | From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On | Behalf Of Bruno Delbono | Sent: Thursday, November 14, 2013 10:48 AM | To: Theo de Raadt | Cc: misc@openbsd.org; mlar...@azathoth.net | Subject: Re: QEMU CPU cores not showing up | Useless crying removed... | PS - Telling me to stick a screw driver in my ear? Ya seriously eff off...I am not | putting up with this bulling shit. :) Good, I for one am glad you are leaving and taking your self-entitled attitude with you. If you want something fixed that no developer cares about, then shut up and code it yourself. Prick, indeed. -Breeno
Supported PCI express audio devices?
Hi, I need to get audio support working with one of Supermicro's Atom mainboards. These do not have onboard sound, but do have one free PCI express slot. This machine will replace an aging Windows XP audio logger at our local community radio station. I'm not having much luck determining if OpenBSD supports any available PCI express audio devices. Does anyone on the list have suggestions for specific instances of known working hardware? Thanks. Breen Ouellette
Re: PF altq and limiting traffic among multiple interfaces
| -Original Message- | From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On | Behalf Of Stuart Henderson | Sent: Wednesday, November 21, 2012 7:47 AM | To: misc@openbsd.org | Subject: Re: PF altq and limiting traffic among multiple interfaces | | On 2012-11-21, openbsd2012 openbsd2...@breeno.net wrote: | In short, the problem with keeping state across interfaces (PF's | default) is that it makes it impractical, if not impossible, to have | packets in different queues on both your internal and external network | interfaces. To fix this, you need to configure PF to keep state on a | per interface basis. This is done with a declaration in PF of set | state-policy if-bound. | | There's another way which I think is better: | | Give the queues the *same names* on the different interfaces. Stuart, I'm finally getting some time to try out like-named queues on multiple interfaces, but I'm not getting the result you previously indicated. Packets originating on my internal network are being matched to the correct queues, but after being NAT'ed they are flowing through the default queue on the external interface. Likewise, packets originating on external networks are queuing correctly to my external interface, but after being NAT'ed they then flow through the default queue on the internal interface. I have not implemented your match rules, as my preference is to queue on the pass rule. However, I haven't seen anything that would indicate that match rules transcend state tracking, which is the only way I can see that using match rules could have an effect. Does your output from 'systat queues' actually show that you have packets hitting your like-named queues on the interface opposite of packet origination? Breen
Re: Hunning HA over multiple ARCH's
If you really find that you are considering going Soekris, you might also want to consider one of these: http://www.supermicro.com/products/system/1U/5015/SYS-5015A-EHF-D525.cfm Unless you need the second PCI-E slot that the net6501 offers. I don't see much advantage to the marginally smaller form factor when going rack mount. Breeno | -Original Message- | From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On | Behalf Of Joel Wiramu Pauling | Sent: Tuesday, December 04, 2012 4:42 PM | To: loic.b...@frostsapphirestudios.com | Cc: misc@openbsd.org | Subject: Re: Hunning HA over multiple ARCH's | | Sounds like I should retire the v215 - I was hoping I might be able to prolong | it's life as part of the HA setup; it boots very quickly in comparison to the HP | hardware something quite useful in a Firewall - but seems I should perhaps | put a Soekris or something else in-line for that purpose. |
Re: softraid to encrypt _AND_ raid?
| -Original Message- | Alexis de BRUYN [Mailinglists] wrote | Try that : | wd0a wd1a are RAID partitions. | bioctl -c 1 -l wd0a,wd1a softraid0 | Create a RAID partition on the new raid device sd0. | bioctl -c C -r 8192 -l /dev/sd0d softraid0 | sd1 is your raid+crypto device. | | Thanks for the tip, but unfortunately it didn't work (that's what I had tried). | However, I think I found a workaround: after combining wd0a and wd1a as | mirrors with the first command, I created a disklabel for sd0, with a sd0a of | type raid | | Then: bioctl -c C -r 8192 -l /dev/sd0a softraid0 Sorry to interrupt, but I just want to clarify. It didn't work when you tried: [1] a disklabel with sd0d of type raid; then [2] bioctl -c C -r 8192 -l /dev/sd0d softraid0 But it did work when you tried: [1] a disklabel with sd0a of type raid; then [2] bioctl -c C -r 8192 -l /dev/sd0a softraid0 The singular question that this raises for me is... are you quite sure that your disklabel for the sd0d attempt was error free? Thanks for your indulgence. Breeno
Re: OpenBSD Cloud Offerings
| -Original Message- | Subject: OpenBSD Cloud Offerings | | I was wondering if anyone had any experience with reputable cloud | providers that currently offer OpenBSD 5.2. | | I was able to find out some information based on the OpenBSD Journal | posting from Sunday, February 13, 2011 titled OpenBSD Private Cloud | Computing. The two vendors mentioned included ARP Networks and | RootBSD. Do you mean VPS? I didn't know that ARP offered cloud services. However, if you are interested in VPS providers, I'll start with the usual warning: OpenBSD's security is subject to the security of the VPS host, which it is generally safe to say is not as secure as an OpenBSD default install. That said, I've been happy with my results from corgitech.com. I've got a couple VPS containers with them. They have multiple available datacenters, VMWare ESXi 5.1 performs well with OpenBSD, good bandwidth, fast support response times, and their prices are great. They recently had a ecoupon for 50% of their services: CORGI50. If it still works you are getting one hell of a deal. I've also happily used bsdvm.com, with my only complaints being that they [1] use older VMware software, and [2] default to placing their VPS containers behind virtualized NAT (but you can request bridging, if you know to ask for it). Otherwise the service is comparable to corgitech.com, with the exception that bsdvm.com only uses one datacenter - Hurricane Electric. I'd really like to recommend amerinoc.com because they have excellent plans and service, but they use Xen on Linux, which performs poorly with OpenBSD because there are no PV drivers. I tried but couldn't convince them to offer an ESXi service. If someone - with skills beyond mine - gets motivated to complete Xen PV drivers for OpenBSD I will definitely go back to hosting OpenBSD with them. All that said, if you can afford $100 per month you should look into a dedicated server rather than VPS or cloud. You'll have to search and may need to wait for a special to be offered, but reliable dedicated providers can be found at that price point. The reason I stick with VPS is two-fold: [1] I'm a poor law student, and [2] it offers me the ability to host with several providers for redundancy. At my budget an OpenBSD VPS beats Linux shared hosting in every way. Breen
Re: PF altq and limiting traffic among multiple interfaces
facepalm And here I've been doing it the hard way! I'll definitely give this
a whirl on my next break. I don't recall ever seeing anything in the PF FAQ or
manpage regarding identical naming of queues across interfaces. Is this the
intended behavior, or a happy coincidence?
Thanks for the insight!
Breen
-Original Message-
From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of
Stuart Henderson
Sent: Wednesday, November 21, 2012 7:47 AM
To: misc@openbsd.org
Subject: Re: PF altq and limiting traffic among multiple interfaces
On 2012-11-21, openbsd2012 openbsd2...@breeno.net wrote:
In short, the problem with keeping state across interfaces (PF's
default) is that it makes it impractical, if not impossible, to have
packets in different queues on both your internal and external network
interfaces. To fix this, you need to configure PF to keep state on a
per interface basis. This is done with a declaration in PF of set
state-policy if-bound.
There's another way which I think is better:
Give the queues the *same names* on the different interfaces.
Here's a slightly tweaked excert from one of my pf.conf files. The hfsc config
may be a bit wrong as I only have a rough idea how to write hfsc rules (pieced
together from posts on pfsense forums and Jacek Artymiak's old book), but it
works OK in practice and is enough to show the idea.
Also, I find it much easier to deal with queue assignment in one place,
separate from the filter rules, so I do this all in one block using match rules.
altq on pppoe0 hfsc bandwidth 820Kb queue {fast, med, low, bulk}
queue fast on pppoe0 bandwidth 30% priority 8 qlimit 20 hfsc (realtime 180Kb)
queue med on pppoe0 bandwidth 5% priority 4 qlimit 40 hfsc (realtime (200Kb,
1, 60Kb))
queue low on pppoe0 bandwidth 20% priority 2 qlimit 50 hfsc (realtime (200Kb,
1, 60Kb) default)
queue bulk on pppoe0 bandwidth 5% priority 1 qlimit 50 hfsc
altq on vr3 hfsc bandwidth 80Mb queue {local, internet}
queue local on vr3 bandwidth 1% priority 8 qlimit 50 hfsc (realtime 50Mb
upperlimit 50Mb)
queue internet on vr3 bandwidth 3Mb priority 8 qlimit 50 hfsc (realtime 3Mb
upperlimit 3Mb) {fast, med, low, bulk}
queue fast on vr3 bandwidth 1% priority 8 qlimit 50 hfsc (realtime 256Kb)
queue med on vr3 bandwidth 1% priority 4 qlimit 50 hfsc (realtime (800Kb,
1, 256Kb) upperlimit 800Kb)
queue low on vr3 bandwidth 1% priority 2 qlimit 50 hfsc (realtime (500Kb,
1, 256Kb) upperlimit 500Kb default)
queue bulk on vr3 bandwidth 1% priority 1 qlimit 50 hfsc
match proto tcp queue (low fast)
match proto tcp to port {http https} queue (med fast)
match proto udp from port {ntp domain snmp} queue (fast) match proto udp to
port {ntp domain snmp} queue (fast)
match proto tcp from port domain queue (fast) match proto tcp to port domain
queue (fast)
match proto tcp from port smtp queue (bulk) match proto tcp to port smtp queue
(bulk)
match proto udp from $pbx queue fast
match proto udp to $pbx queue fast
Re: PF altq and limiting traffic among multiple interfaces
Mikolaj,
Before I get into this, do you really have a connection where your total
bandwidth in both directions is pooled? If so you will need to modify my
approach somewhat, as I've not been in that situation myself.
For reference, my full rule set for my home network appears at the end of this
message.
PF only queues on outbound traffic, so to shape your traffic in both directions
you must be operating PF in a router or bridge configuration. People sometimes
make the mistake of thinking that this means that PF cannot queue download
traffic. As I said earlier, PF cannot queue inbound traffic on an interface.
There is a difference between queuing inbound traffic and queuing download,
because inbound traffic relates to an interface while download is applied as a
perspective dependent concept. With the correct configuration, you can
configure your external interface to queue packets for upload and your
internal interface to queue packets for download. I use quotes to indicate
that these terms are relative to the perspective of a machine behind your
router on your internal network.
In short, the problem with keeping state across interfaces (PF's default) is
that it makes it impractical, if not impossible, to have packets in different
queues on both your internal and external network interfaces. To fix this, you
need to configure PF to keep state on a per interface basis. This is done with
a declaration in PF of set state-policy if-bound.
Once that is done, a little extra work needs to be done with your pass rules.
1. You will have to determine a way to identify the priority of new packets
that you wish to pass in from your internal network, such as by IP, IP range,
VLAN, or real interface. On each of those pass in rules you will assign the
packet to the corresponding queue on the external interface and tag the packet
with an identifier for the type of queuing it needs.
2. On your external interface you will need pass out rules that sort the
traffic according to how they were tagged by the internal interface pass in
rule. The pass out rule will assign the packet to the corresponding queue on
the internal interface.
3. The mechanism of keeping state will take care of the rest.
4. If you plan to have any open ports on your external interface (ssh, http,
bittorrent), you will need to repeat the above using the external interface in
step 1, and the internal interface in step 2.
5. You will also need at least one rule to allow packets to pass out from each
interface on the router/bridge machine itself. You can queue these specifically
or let them go to the default queue. The examples of this in my rule set below
should be evident if you take the time to understand it.
You might also want to read a question I asked a few days ago on this list. It
will help you to understand a strange limitation I've encountered with this
type of configuration. See
http://marc.info/?l=openbsd-miscm=135325644931124w=2 if you are interested.
No one has responded to that message, so I am not sure if the defect exists in
my rule set or in PF itself. My intuition tells me that PF is the problem, but
my experience tells me that my intuition cannot be trusted in these matters. :)
I hope this is what you were looking for.
Breen Ouellette
---
# PF optimized for home router.
# UPDATED: 2012-Nov-17
###
# Preamble:
# REMEMBER: Enable the following line in /etc/sysctl.conf:
# net.inet.ip.forwarding=1
# Blocked1Hr table requires matching crontab entry to expire blocked IPs:
# * * * * * pfctl -t Blocked1Hr -T expire 3600
/dev/null 21
# Filtering of ssh abusers also requires that sshd_config is updated to listen
on ports 10 and 16.
ExtIf = em1
ExtIP = (em1)
IntIf = em0
VLAN1If = vlan1
VLAN1Net = vlan1:network
VLAN2If = vlan2
VLAN2Net = vlan2:network
AthenaIP = 172.16.0.1
ScreenerIP = 172.16.0.2
LGO2XIP = 192.168.0.100
SkypeIP = 192.168.0.50
table authpf_users persist
table Blocked1Hr persist
table SSHBlockedOnce persist
table SSHBlockedTwice persist
table SSHBlockedPerm persist
table CdnNets const persist file /etc/cdn_nets.pftable
table MartianNets const persist file /etc/martian_nets.pftable
table SSHAllowedIPs const persist file /etc/ssh_ips.pftable
# Internal network queuing.
altq on $IntIf cbq bandwidth 5250Kb queue \
{ LGO2X_DL, PC_DL, Skype_DL, TV_DL, WiFi_DL }
queue LGO2X_DL bandwidth 650Kb priority 2 cbq(borrow ecn)
queue PC_DL bandwidth 1500Kb priority 1 cbq(borrow ecn default)
queue Skype_DL bandwidth 100Kb priority 2 cbq(ecn)
queue TV_DL bandwidth 2000Kb priority 1 cbq(borrow ecn)
queue WiFi_DL bandwidth 1000Kb priority 1 cbq(borrow ecn)
# ISP network queuing.
altq on $ExtIf cbq bandwidth 550Kb queue \
{ ACK_UL, LGO2X_UL, PC_UL, Skype_UL, TV_UL, WiFi_UL }
# 27400bps ACK_UL is required for each 1Mbps of total download bandwitdh,
# assuming a 40bit ACK packet size. Real world results may vary and
Parent-child cbq borrow irregularity with pf
Hello list members. Long time no see. Law school hasn't been kind to my free
time.
I have noticed this unexpected behavior in pf since OpenBSD 5.0-release on
various amd64 boxes. I am using cbq in pf to throttle outbound traffic on both
interfaces of my home router. Full pf rule set and dmesg appear at the end of
this email.
The external interface on the router is connected to ADSL with total provided
bandwidth of approximately 5500Kb. The internal interface is an em on a 1Gb
network.
Compare these two blocks of pf queue configuration:
# Block #1
altq on $IntIf cbq bandwidth 5250Kb queue \
{ LGO2X_DL, PC_DL, Skype_DL, TV_DL, WiFi_DL }
queue LGO2X_DL bandwidth 650Kb priority 2 cbq(borrow ecn)
queue PC_DL bandwidth 1500Kb priority 1 cbq(borrow ecn default)
queue Skype_DL bandwidth 100Kb priority 2 cbq(ecn)
queue TV_DL bandwidth 2000Kb priority 1 cbq(borrow ecn)
queue WiFi_DL bandwidth 1000Kb priority 1 cbq(borrow ecn)
# Block #2
altq on $IntIf cbq bandwidth 5253Kb queue \
{ PARENT }
queue PARENT bandwidth 5250Kb \
{ LGO2X_DL, PC_DL, Skype_DL, TV_DL, WiFi_DL }
queue LGO2X_DL bandwidth 650Kb priority 2 cbq(borrow ecn)
queue PC_DL bandwidth 1500Kb priority 1 cbq(borrow ecn default)
queue Skype_DL bandwidth 100Kb priority 2 cbq(ecn)
queue TV_DL bandwidth 2000Kb priority 1 cbq(borrow ecn)
queue WiFi_DL bandwidth 1000Kb priority 1 cbq(borrow ecn)
Block #1 performs as expected. The queues receive their guaranteed minimum
allotment, and can borrow bandwidth up to the maximum allotted to the
interface.
One might expect the queues under PARENT in block #2 to perform in the same
fashion. They do not.
- When the bandwidth allocation for the interface is more than 3Kb
greater than the bandwidth allocation for the PARENT queue, borrowing by the
child queues is degraded significantly. Given block #2 above, the following
performance was noted:
o With interface bandwidth allocated at 5253Kb the child queues only borrow
to approximately 3200Kbps;
o With interface bandwidth allocated at 1Gb the child queues only borrow to
approximately 2600Kbps.
- When the bandwidth allocation for the interface is between 5250Kb
and 5252Kb the child queues perform as they do using the configuration in
block #1.
- When cbq(borrow) is configured on the parent queue the child queues
can achieve the maximum bandwidth of the external interface.
This configuration was also tested:
#Block 3
altq on $IntIf cbq bandwidth 5250Kb queue \
{ PARENT }
queue PARENT bandwidth 2500Kb \
{ LGO2X_DL, PC_DL, Skype_DL, TV_DL, WiFi_DL }
queue LGO2X_DL bandwidth 500Kb priority 2 cbq(borrow ecn)
queue PC_DL bandwidth 500Kb priority 1 cbq(borrow ecn default)
queue Skype_DL bandwidth 500Kb priority 2 cbq(ecn)
queue TV_DL bandwidth 500Kb priority 1 cbq(borrow ecn)
queue WiFi_DL bandwidth 500Kb priority 1 cbq(borrow ecn)
In this case, the child queues would not borrow past 650Kb total bandwidth.
The anticipated behavior was a borrow to 2500Kb.
Is there an explanation for this behavior, other than an error in pf itself?
This outcome does not seem to follow from the documentation, neither with the
man pages nor the pf FAQ.
Thanks.
Breen Ouellette
Full pf rule set:
# PF optimized for home router.
# UPDATED: 2012-Nov-17
###
# Preamble:
# REMEMBER: Enable the following line in /etc/sysctl.conf:
# net.inet.ip.forwarding=1
# Blocked1Hr table requires matching crontab entry to expire blocked IPs:
# * * * * * pfctl -t Blocked1Hr -T expire 3600
/dev/null 21
# Filtering of ssh abusers also requires that sshd_config is updated to listen
on ports 10 and 16.
ExtIf = em1
ExtIP = (em1)
IntIf = em0
VLAN1If = vlan1
VLAN1Net = vlan1:network
VLAN2If = vlan2
VLAN2Net = vlan2:network
AthenaIP = 172.16.0.1
ScreenerIP = 172.16.0.2
LGO2XIP = 192.168.0.100
SkypeIP = 192.168.0.50
table authpf_users persist
table Blocked1Hr persist
table SSHBlockedOnce persist
table SSHBlockedTwice persist
table SSHBlockedPerm persist
table CdnNets const persist file /etc/cdn_nets.pftable
table MartianNets const persist file /etc/martian_nets.pftable
table SSHAllowedIPs const persist file /etc/ssh_ips.pftable
# Internal network queuing.
altq on $IntIf cbq bandwidth 5250Kb queue \
{ LGO2X_DL, PC_DL, Skype_DL, TV_DL, WiFi_DL }
queue LGO2X_DL bandwidth 650Kb priority 2 cbq(borrow ecn)
queue PC_DL bandwidth 1500Kb priority 1 cbq(borrow ecn default)
queue Skype_DL bandwidth 100Kb priority 2 cbq(ecn)
queue TV_DL bandwidth 2000Kb priority 1 cbq(borrow ecn)
queue WiFi_DL bandwidth 1000Kb priority 1 cbq(borrow ecn)
# ISP network queuing.
altq on $ExtIf cbq bandwidth 550Kb queue \
{ ACK_UL, LGO2X_UL, PC_UL, Skype_UL, TV_UL, WiFi_UL }
# 27400bps ACK_UL is required for each 1Mbps of total download bandwitdh,
# assuming a 40bit ACK packet size. Real world results may vary and
values
# used here were derived through
