<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 12:56 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">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 at<br>
> least - going with SBD will probably give you more issues than it will help<br>
> you.<br>
> […]<br>
> But again I would encourage you to try something different unless you need<br>
> 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></blockquote><div><br></div><div>No, given you have a reliable watchdog and the timeouts are configured</div><div>properly SBD should be safe - both with and without shared disks.</div><div>The shared disks don't add additional safety actually because SBD</div><div>anyway has to rely on the watchdog taking the node down reliably</div><div>shouldn't it be able to access the disk(s) anymore.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
And - appart from the single hv node - what's wrong with SBD on<br>
"virtualized" raw shared storage? Any bad field experience?<br></blockquote><div><br></div><div>Nothing is basically wrong. Of course a reliable watchdog might be</div><div>an issue in virtual environments and a fallback to softdog will never</div><div>give you the reliability of a piece of hardware ticking down independently</div><div>from CPU and everything.</div><div>What I meant was that if you are running all your VMs on a single</div><div>hypervisor there is really no need to be able to cope with a split-network</div><div>szenario or anything like this. So why add something additional that needs</div><div>careful arrangement of timeouts, possibly disk(s), ... if your</div><div>hypervisor already offers an interface that allows you to control a</div><div>VM and that gives you reliable feedback of the status and which is</div><div>probably roughly as available as the hypervisor itself.</div><div><br></div><div>Regards,</div><div>Klaus</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Thanks!<br>
<br>
</blockquote></div></div>