<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">I've deployed a new kernel on all of our production ganeti nodes and the systems seem to be running better now. I'll keep an eye on it for the next few days to be sure everything is still working properly.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Thanks-</div><br><div class="gmail_quote"><div dir="ltr">On Thu, Sep 6, 2018 at 8:31 AM Lance Albertson <<a href="mailto:lance@osuosl.org">lance@osuosl.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div style="font-family:arial,helvetica,sans-serif">Hi all,</div><div style="font-family:arial,helvetica,sans-serif"><br></div><div style="font-family:arial,helvetica,sans-serif">I wanted to send you an update on this situation as it seems to keep happening. Unfortunately it doesn't seem that RHEL has released a new kernel which resolves this issue. Over the past few days I've been rebooting nodes to apply the L1TF vulnerability fixes which of course means these nodes are now running the kernel which has this bug. This has made the cluster more unstable unfortunately causing multiple reboots a day.</div><div style="font-family:arial,helvetica,sans-serif"><br></div><div style="font-family:arial,helvetica,sans-serif">I'm currently working on deploying a new mainline kernel to mitigate this issue and hope to have it deployed by the end of today.</div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Aug 27, 2018 at 1:01 PM Lance Albertson <<a href="mailto:lance@osuosl.org" target="_blank">lance@osuosl.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div style="font-family:arial,helvetica,sans-serif">All,</div><div style="font-family:arial,helvetica,sans-serif"><br></div><div style="font-family:arial,helvetica,sans-serif">We've been having issues with our Ganeti cluster hypervisors randomly rebooting. So far we've had this happen four times within the last month (including this morning) at the following times (in UTC) and duration:</div><div style="font-family:arial,helvetica,sans-serif"><br></div><div><font face="arial, helvetica, sans-serif">Event Start Time<span style="white-space:pre-wrap">   </span>Event End Time<span style="white-space:pre-wrap">  </span>Event Duration</font><br></div><div><font face="arial, helvetica, sans-serif">2018-07-27 10:25:13<span style="white-space:pre-wrap">       </span>2018-07-27 10:29:29<span style="white-space:pre-wrap">     </span>0d 0h 4m 16s</font><br></div><div><font face="arial, helvetica, sans-serif">2018-07-28 17:03:19<span style="white-space:pre-wrap"> </span>2018-07-28 17:06:57<span style="white-space:pre-wrap">     </span>0d 0h 3m 38s<br></font></div><div><font face="arial, helvetica, sans-serif">2018-08-23 08:14:07<span style="white-space:pre-wrap"> </span>2018-08-23 08:18:00<span style="white-space:pre-wrap">     </span>0d 0h 3m 53s<br></font></div><div><font face="arial, helvetica, sans-serif">2018-08-27 11:46:06<span style="white-space:pre-wrap"> </span>2018-08-27 11:48:44<span style="white-space:pre-wrap">     </span>0d 0h 2m 38s<span style="white-space:pre-wrap">    </span><br></font></div><div style="font-family:arial,helvetica,sans-serif"><br></div><div style="font-family:arial,helvetica,sans-serif">The kernel log points to this [1] upstream issue for RHEL and also reported on the CentOS forum [2] (We run CentOS 7 on our servers).</div><div style="font-family:arial,helvetica,sans-serif"><br></div><div style="font-family:arial,helvetica,sans-serif"><div>[1] <a href="https://access.redhat.com/solutions/3432391" target="_blank">https://access.redhat.com/solutions/3432391</a></div><div>[2] <a href="https://www.centos.org/forums/viewtopic.php?t=67170" target="_blank">https://www.centos.org/forums/viewtopic.php?t=67170</a></div></div><div style="font-family:arial,helvetica,sans-serif"><br></div><div style="font-family:arial,helvetica,sans-serif">It seems the solution is "In progress" so I expect it to be included in the next released kernel in CentOS. Unfortunately the workaround is to either use an older kernel or just wait. As of right now we are going to opt to wait until the next release happens however if we see increased instability we'll look into using an older kernel.</div><div style="font-family:arial,helvetica,sans-serif"><br></div><div style="font-family:arial,helvetica,sans-serif">So far this only affects our Ganeti cluster and hasn't been triggered in either of our OpenStack clusters (x86 & ppc64le) as of yet. <br></div><div style="font-family:arial,helvetica,sans-serif"><br></div><div style="font-family:arial,helvetica,sans-serif">For some of our older VMs which boot using an external kernel we build, we've been hitting a different problem with the dracut dropping to an emergency shell if there are any fsck warnings on boot. We've had to manually fsck those filesystems and reboot the VMs to bring them back online. We're hoping to move away from these external kernels soon so let us know if you'd like to do that. In the meantime, we're going to look and see what changes we can make with the initrd so that it doesn't drop into the emergency shell and let's the OS do the fsck instead. We recently updated those external kernels to use an initrd which is why this has started to happen.</div><div style="font-family:arial,helvetica,sans-serif"><div><br></div></div><div style="font-family:arial,helvetica,sans-serif">The RH solution page has the following upstream commit message which explains why this bug is happening in the kernel:</div><div style="font-family:arial,helvetica,sans-serif"><br></div><div><div><font face="arial, helvetica, sans-serif">    Because we drop cpu_base->lock around calling hrtimer::function, it is</font></div><div><font face="arial, helvetica, sans-serif">    possible for hrtimer_start() to come in between and enqueue the timer.</font></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif">    If hrtimer::function then returns HRTIMER_RESTART we'll hit the BUG_ON</font></div><div><font face="arial, helvetica, sans-serif">    because HRTIMER_STATE_ENQUEUED will be set.</font></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif">    Since the above is a perfectly valid scenario, remove the BUG_ON and</font></div><div><font face="arial, helvetica, sans-serif">    make the enqueue_hrtimer() call conditional on the timer not being</font></div><div><font face="arial, helvetica, sans-serif">    enqueued already.</font></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif">    NOTE: in that concurrent scenario its entirely common for both sites</font></div><div><font face="arial, helvetica, sans-serif">    to want to modify the hrtimer, since hrtimers don't provide</font></div><div><font face="arial, helvetica, sans-serif">    serialization themselves be sure to provide some such that the</font></div><div><font face="arial, helvetica, sans-serif">    hrtimer::function and the hrtimer_start() caller don't both try and</font></div><div><font face="arial, helvetica, sans-serif">    fudge the expiration state at the same time.</font></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif">    To that effect, add a WARN when someone tries to forward an already</font></div><div><font face="arial, helvetica, sans-serif">    enqueued timer, the most common way to change the expiry of self</font></div><div><font face="arial, helvetica, sans-serif">    restarting timers. Ideally we'd put the WARN in everything modifying</font></div><div><font face="arial, helvetica, sans-serif">    the expiry but most of that is inlines and we don't need the bloat.</font></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif">If you have any questions or concerns please let us know.</font></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif">Thanks!</font></div><div><font face="arial, helvetica, sans-serif"><br></font></div></div>-- <br><div dir="ltr" class="m_8589157800713396765m_-8318797372025064032gmail_signature"><div dir="ltr"><font face="arial, helvetica, sans-serif">Lance Albertson</font><div><div><font face="arial, helvetica, sans-serif">Director</font></div><div><span style="font-family:arial,helvetica,sans-serif">Oregon State University | </span><span style="font-family:arial,helvetica,sans-serif">Open Source Lab </span></div></div></div></div></div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="m_8589157800713396765gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><font face="arial, helvetica, sans-serif">Lance Albertson</font><div><div><font face="arial, helvetica, sans-serif">Director</font></div><div><span style="font-family:arial,helvetica,sans-serif">Oregon State University | </span><span style="font-family:arial,helvetica,sans-serif">Open Source Lab </span></div></div></div></div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><font face="arial, helvetica, sans-serif">Lance Albertson</font><div><div><font face="arial, helvetica, sans-serif">Director</font></div><div><span style="font-family:arial,helvetica,sans-serif">Oregon State University | </span><span style="font-family:arial,helvetica,sans-serif">Open Source Lab </span></div></div></div></div></div>