Hi List,

I was building vdsm from git master on a newly installed minimal F20.
I get the following when trying to start vdsm:

    vdsm: Running mkdirs
    vdsm: Running configure_coredump
    vdsm: Running run_init_hooks
    vdsm: Running gencerts
    vdsm: Running check_is_configured
    libvirt is not configured for vdsm yet
    Traceback (most recent call last):
      File "/usr/bin/vdsm-tool", line 145, in <module>
      File "/usr/bin/vdsm-tool", line 142, in main
        return tool_command[cmd]["command"](*args[1:])
      File "/usr/lib64/python2.7/site-packages/vdsm/tool/configurator.py", line 
224, in isconfigured
        if c.getName() in args.modules and not c.isconfigured()
      File "/usr/lib64/python2.7/site-packages/vdsm/tool/configurator.py", line 
166, in isconfigured
        raise RuntimeError("sanlock service requires restart")
    RuntimeError: sanlock service requires restart
    vdsm: failed to execute check_is_configured, error code 1

A brief look at lib/vdsm/tool/configurator.py makes me see that:

--pre-start calls configurator.py:configure()

that configure() checks all the configurers and calls isconfigured() on them to
determine which should be stopped, configured and started again.

that SanlockMonduleConfigure, instead of returning False when the sanlock user
has been added to the kvm and qemu groups raises an exception instead of
returning False.

This exception raising seems counterintuitive, shouldn't we only raise
exception if a configuration is not possible? I manually stopped sanlock:
    systemctl stop sanlock
and performed the configuration step in configurator.py
    usermod -a -G qemu,kvm sanlock
and after this /proc/$sanlock_pid/status reported the proper pid.

Is there something I am missing for which it is necessary to raise and prevent
the configuring?


vdsm-devel mailing list

Reply via email to