On Mon, Jul 28, 2025 at 12:56 PM Jehan-Guillaume de Rorthais < j...@dalibo.com> wrote:
> Hi Klaus, > > On Thu, 24 Jul 2025 17:56:31 +0200 > Klaus Wenninger <kwenn...@redhat.com> wrote: > > > […] > > If you have a single hypervisor where you have access to - some sort of > at > > least - going with SBD will probably give you more issues than it will > help > > you. > > […] > > But again I would encourage you to try something different unless you > need > > any of the points where SBD shines. > > I would be interested if you could you elaborate a bit on that? > > Is it that SBD for watchdog self-fencing only architecture is considered > instable or insecure? How would it be? > No, given you have a reliable watchdog and the timeouts are configured properly SBD should be safe - both with and without shared disks. The shared disks don't add additional safety actually because SBD anyway has to rely on the watchdog taking the node down reliably shouldn't it be able to access the disk(s) anymore. > > And - appart from the single hv node - what's wrong with SBD on > "virtualized" raw shared storage? Any bad field experience? > Nothing is basically wrong. Of course a reliable watchdog might be an issue in virtual environments and a fallback to softdog will never give you the reliability of a piece of hardware ticking down independently from CPU and everything. What I meant was that if you are running all your VMs on a single hypervisor there is really no need to be able to cope with a split-network szenario or anything like this. So why add something additional that needs careful arrangement of timeouts, possibly disk(s), ... if your hypervisor already offers an interface that allows you to control a VM and that gives you reliable feedback of the status and which is probably roughly as available as the hypervisor itself. Regards, Klaus > > Thanks! > >
_______________________________________________ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/
