Re: Openbsd 6.1 and Current Console Freezes and lockup Proxmox PVE5.0

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Openbsd 6.1 and Current Console Freezes and lockup Proxmox PVE5.0

Tom Smyth
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|

Re: Openbsd 6.1 and Current Console Freezes and lockup Proxmox PVE5.0

Tom Smyth
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|

Re: Openbsd 6.1 and Current Console Freezes and lockup Proxmox PVE5.0

Tom Smyth
Hello All,

im just updating a legacy thread on Proxmox KVM Hosts for OpenBSD Guuests
The KVM / Proxmox 5.x  Preemption timer in Linux Kernel In proxmox 5.3 ...
OpenBSD 6.4 Guests work fine without any modifications to the
Proxmox System, (ie you no lonter need to disable the)
/sys/module/kvm_intel/parameters/preemption_timer

so OpenBSD Runs fine on an unmodified Proxmox 5.3 Box ...
so the KVM / Linux Bug that caused OpenBSD guests to Freeze  seems
to be resolved in Proxmox  5.3 ...  (so users of 5.0 , 5.1 may want to
upgrade
to the latest version of Proxmox

I hope this helps
Tom Smyth


On Mon, 15 Jan 2018 at 21:34, Tom Smyth <[hidden email]>
wrote:

> 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 <[hidden email]>
> 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 <[hidden email]>
> 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 <[hidden email]> 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 <[hidden email]>
> 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
> >>>>
> >>>
> >