Hello all, I just want to reference the following post which resolved my issues of running OpenBSD guests on Proxmox 5.x
Just to clarify Todds / Stefans Email in another thread (Thanks Stefan and Todd,) https://marc.info/?l=openbsd-misc&m=151600765414976&w=2 disable kvm_intel.preemption_timer on the host (see \ > /sys/module/kvm_intel/parameters/preemption_timer ) This seems to be buggy in > linux \ > 4.10 and newer disabling intel-kvm preemption_timer worked for me and it resolved the timer drift issue in openbsd on Proxmox 5.1 so in debian / proxmox I ran the following command echo options kvm-intel preemption_timer=N >>/etc/modprobe.d/kvm-intel.conf Thanks, Tom Smyth On 30 December 2017 at 23:25, Tom Smyth <tom.sm...@wirelessconnect.eu> wrote: > Hello I have repeated OpenBSD 6.2 Testng on Proxmox PVE > 5.1 3r Relasee CD > > The console does not hang like in previous releases of Proxmox > PVE 5.x > However the issue of delays between pings (slow sleep time) stil > is there since the 5.1 Release 2 and is present in 5.1 release 3 iso > (the Proxmox 5.1 CD that was released 22 December 2017 > > if I do date;sleep 1;date > I will get the first time and date, and the second time about > 9-11 seconds after the first... and the interval between pings is > sporadic... I will raise a case with Proxmox again about this > Ill do some further digging... > Thanks > > On 27 October 2017 at 07:18, Tom Smyth <tom.sm...@wirelessconnect.eu> wrote: >> Hello Theo, Mike, All, >> >> @Theo Understood it is important to protect developers and the project goals >> ... @Mike Thanks for your Generosity in the time you took on this thread, >> Yes I want Mike to make VMM more awesome :) @Mike keep up the good work >> >> I cant disagree with any point that Theo made in his email on this tread >> that said, >> unfortunately I cant always choose my hypervisor and I dearly want to run >> OpenBSD on it proxmox... >> >> I do think (based on the fact that OpenBSD 6.0-6.2 works on PVE 4.4 it is >> probably a (virtual Hardware issue ) .. not necessarily an OpenBSD issue >> I will raise this with the PVE Support guys (as I have already done since mid >> July ) >> >> Any further posts on this thread from me will be (hopefully for other OpenBSD >> users benefit (if I make progress) >> and certainly not intended as a request or a distraction for Core >> OpenBSD Developers >> >> All the Best, >> >> Tom Smyth >> >> On 27 October 2017 at 06:37, Theo de Raadt <dera...@openbsd.org> wrote: >>> Tom, >>> >>> A virtual machine setup is an operating system running on an operating >>> system on top of an operating system. >>> >>> OK, not quite. The middle one, the VM itself, is as a bit less >>> complex than a full operating system as machine-independent code goes, >>> but nevertheless the machine-dependent bat-shit-crazy stuff is far >>> more complex with gobs of extremely messy nuances face it on both >>> sides because x86 is a fucking minefield >>> >>> Everyone needs to adjust their expectation that all 3 layers are >>> perfect, AND not assume that it is our layer doing the wrong thing >>> >>> Really the layers should simplify but the current marketplace is still >>> gaining more value out of product differentiation than >>> simplification+convergence, both sw and hw >>> >>> Even if our subsystem isn't doing something 'right', it is NOT the >>> stated goal of OpenBSD to run well on every garbage VM, because it has >>> become impossible for the little guy to be perfect. >>> >>> Concerted efforts to diagnose and improve these low-level issues uses >>> the same crowd of people who are trying to improve other edges which >>> may be more important. do you want our vmm to work well? or do you >>> want us to work better on someone else's vmm? Sorry, limited >>> skillset, pick what you want mlarkin to focus on! But that is unfair, >>> and even if he listened to your wishlist, UNPRODUCTIVE. >>> >>> Where does this go? Get ready for monopolies in everything, or >>> oligopolies at best... or fight their establishment. >>> >>>> Just to say the gaps in ping response seems get worse as the uptime >>>> increases >>>> ie >>>> with the uptime around 5 minutes the gaps between ping results are around >>>> 1 sec >>>> (what I consider normal) >>>> with the uptime around 2 hrs 45 minutes the gaps between ping results are >>>> 13 sec >>>> with the uptime 8 hrs 30 minutes the gaps between ping results are 35 >>>> seconds >>>> >>>> Output of sysctl kern.timecounter below >>>> >>>> kern.timecounter.tick=1 >>>> kern.timecounter.timestepwarnings=0 >>>> kern.timecounter.hardware=acpihpet0 >>>> kern.timecounter.choice=i8254(0) acpihpet0(1000) acpitimer0(1000) >>>> dummy(-1000000) >>>> >>>> I will change the ACPI now to i8254 and report back later on >>>> Thanks >>>> >>>> >>>> On 26 October 2017 at 20:25, Mike Belopuhov <m...@belopuhov.com> wrote: >>>> > On Thu, Oct 26, 2017 at 19:05 +0100, Tom Smyth wrote: >>>> >> Lads, >>>> >> >>>> >> Im pleased to say that my testing of OpenBSD 6.1 and OpenBSD 6.2 >>>> >> Release >>>> >> amd64 , >>>> >> appear to work a little better in Proxmox PVE5.1 as released this >>>> >> week, >>>> >> >>>> >> I used iso version 5.1-722cc488-1 from Proxmox >>>> >> Updated on 24 October 2017 >>>> >> >>>> >> The Console no longer freezes but after a few hours >>>> >> the console (vga console accessed via Proxmox webinterface seems >>>> >> to lag a little >>>> >> the interval between pings for instance takes up to 13 seconds, which >>>> >> is a bit strange... ie it takes 13 seconds for each line of Ping result >>>> >> which is u >>>> >> Ill report more feedback later, but at least OpenBSD is not freezing >>>> >> as bad in this >>>> >> version of Proxmox PVE 5.1 >>>> >> >>>> > >>>> > Hi, >>>> > >>>> > Can you please show us the output of "sysctl kern.timecounter". >>>> > If you're currently using an acpihpet0, can you please try >>>> > switching to the acpitimer0 (and if that doesn't help, i8254) via >>>> > >>>> > sysctl kern.timecounter.hardware=acpitimer0 >>>> > >>>> > and attempt to reproduce the 13 secod delay. >>>> > >>>> > Regards, >>>> > Mike >>>> >>> > > > > -- > Kindest regards, > Tom Smyth > > Mobile: +353 87 6193172 > The information contained in this E-mail is intended only for the > confidential use of the named recipient. If the reader of this message > is not the intended recipient or the person responsible for > delivering it to the recipient, you are hereby notified that you have > received this communication in error and that any review, > dissemination or copying of this communication is strictly prohibited. > If you have received this in error, please notify the sender > immediately by telephone at the number above and erase the message > You are requested to carry out your own virus check before > opening any attachment.
