Description of problem:
This is related to bug #843073, which introduced passing io_timeout directly to add_lockspace, ignoring the global io_timeout set by the -o switch. As a result, the io_timeout is always set to the default value of 10 seconds and VMs will be killed after 80 seconds (8 * io_timeout) without any way to adjust this via any configuration file.

This is what happens:

in src/locking/lock_driver_sanlock.c it calls sanlock_add_lockspace (line 337):

    if ((rv = sanlock_add_lockspace(&ls, 0)) < 0) {

Sanlock provides two functions -- one with a way to add a timeout value, and one without (src/client.c:145):

    int sanlock_add_lockspace(struct sanlk_lockspace *ls, uint32_t flags)
    {
        return cmd_lockspace(SM_CMD_ADD_LOCKSPACE, ls, flags, 0);
    }

    int sanlock_add_lockspace_timeout(struct sanlk_lockspace *ls, uint32_t flags, uint32_t io_timeout)
    {
        return cmd_lockspace(SM_CMD_ADD_LOCKSPACE, ls, flags, io_timeout);
    }

Since we call sanlock_add_lockspace, the timeout is hardcoded to 0, which then results in being set to the default value (src/cmd.c:917):

    if (!io_timeout)
        io_timeout = DEFAULT_IO_TIMEOUT;

...which is hardcoded to 10 seconds.

We desperately need a way to adjust lockspace io timeout, otherwise sanlock ALWAYS starts killing VMs after 80 seconds regardless of any configuration settings (like -o).

Suggested mechanism:
1. add io_timeout option to /etc/libvirt/qemu-sanlock.conf with a default setting of 10
2. Call sanlock_add_lockspace_timeout() function instead, passing the timeout specified in the configuration file.


Version-Release number of selected component (if applicable):
0.10.2-54.el6