<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Mon, Jul 28, 2025 at 2:40 PM Jehan-Guillaume de Rorthais <<a href="mailto:jgdr@dalibo.com">jgdr@dalibo.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, 28 Jul 2025 14:10:04 +0200<br>
Klaus Wenninger <<a href="mailto:kwenning@redhat.com" target="_blank">kwenning@redhat.com</a>> wrote:<br>
<br>
> On Mon, Jul 28, 2025 at 12:56 PM Jehan-Guillaume de Rorthais <<br>
> <a href="mailto:jgdr@dalibo.com" target="_blank">jgdr@dalibo.com</a>> wrote:  <br>
> <br>
> > Hi Klaus,<br>
> ><br>
> > On Thu, 24 Jul 2025 17:56:31 +0200<br>
> > Klaus Wenninger <<a href="mailto:kwenning@redhat.com" target="_blank">kwenning@redhat.com</a>> wrote:<br>
> >  <br>
> > > […]<br>
> > > If you have a single hypervisor where you have access to - some sort of  <br>
> > > at least - going with SBD will probably give you more issues than it will<br>
> > > help you.<br>
> > > […]<br>
> > > But again I would encourage you to try something different unless you  <br>
> > > need any of the points where SBD shines.  <br>
> ><br>
> > I would be interested if you could you elaborate a bit on that?<br>
> ><br>
> > Is it that SBD for watchdog self-fencing only architecture is considered<br>
> > instable or insecure? How would it be?<br>
> <br>
> No, given you have a reliable watchdog and the timeouts are configured<br>
> properly SBD should be safe - both with and without shared disks.<br>
<br>
Ok, thank.<br>
<br>
> The shared disks don't add additional safety actually because SBD<br>
> anyway has to rely on the watchdog taking the node down reliably<br>
> shouldn't it be able to access the disk(s) anymore.<br>
<br>
My understanding is that SBD with shared disk is interesting:<br>
<br>
* in shared disk cluster scenario<br>
* to have faster cluster reactions in some circumstances<br></blockquote><div><br></div><div>In some circumstances is true ;-)</div><div>In general the fencing side will have to wait because it might fall back to the</div><div>device being taken down by the watchdog and that isn't any faster as with</div><div>watchdog-fencing. If the target is able to read the poison-pill it will probably<br>reboot kind of instantaneously. But the fencing side will still have to wait.</div><div>Probably not even the node coming back will speed up things as fencing</div><div>will still be pending. But of course the time in between can be used for</div><div>startup of the fenced node and it will be available to run services - if a</div><div>reboot recovers it.</div><div><br></div><div>Regards,</div><div>Klaus</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I should probably get back to the second point though, as I'm not really sure<br>
about it.<br>
<br>
> > And - appart from the single hv node - what's wrong with SBD on<br>
> > "virtualized" raw shared storage? Any bad field experience?<br>
> <br>
> Nothing is basically wrong. Of course a reliable watchdog might be<br>
> an issue in virtual environments and a fallback to softdog will never<br>
> give you the reliability of a piece of hardware ticking down independently<br>
> from CPU and everything.<br>
<br>
Check.<br>
<br>
> What I meant was that if you are running all your VMs on a single<br>
> hypervisor there is really no need to be able to cope with a split-network<br>
> szenario or anything like this. So why add something additional that needs<br>
> careful arrangement of timeouts, possibly disk(s), ... if your<br>
> hypervisor already offers an interface that allows you to control a<br>
> VM and that gives you reliable feedback of the status and which is<br>
> probably roughly as available as the hypervisor itself.<br>
<br>
Well, OK, that's was my understanding as well. I was curious I was missing<br>
something else 😅<br>
<br>
Thank you for the details!<br>
<br>
Have a good day,<br>
<br>
</blockquote></div></div>