On Tue, Mar 13, 2012 at 6:12 PM, David Teigland <teigland(a)redhat.com> wrote:
On Tue, Mar 13, 2012 at 05:46:00PM +0100, Frido Roose wrote:
> I'm not sure if this still makes sense on top of GFS2, but that reminds me
> to the fact that you said sanlock was meant to be used with a block device.
> Maybe this is something that the libvirtd devs need to be aware of. I'll
> start a discussion about this on the libvirt list as the person who tried
> to help me didn't understand the delays neither.
The suggested libvirt sanlock setup uses NFS. When using NFS, you
probably want to tune your io timeout so that id_renewal_fail_seconds is
less than the time it takes your NFS server to restart.
id_renewal_fail_seconds is 8*io_timeout, so with a 10 sec io_timeout, your
NFS server would need to restart within 80 seconds, otherwise the vm's
would be killed.
Yes, and for GFS2, it is similar, but here it's not about the time to
restart, but the time to handle the locking (fencing, journal
recovery, ...) which blocks access to the volume for a specific time.
I'm not that fond of depending on a NFS cluster resource with its own
difficulties when you already have the whole clustering infrastructure
for your virtual environment. Then adding a GFS2 volume is very easy
and clean.
But now I have a better understanding of how it all fits together and
why it behaves like that.
Thanks for your useful help!