On 05/12/2014 05:27 PM, Dan Kenigsberg wrote:
> On Mon, May 12, 2014 at 02:04:05PM +0200, Jiri Moskovcak wrote:
>
>>>>> Jiri, could you describe why you keep your LV active, but not open?
>>>>>
>>>>
>>>> - the setup flow goes approximately like this:
>>>>
>>>> 1. create the LVs for the hosted-engine
>>>> 2. install the engine into the VM
>>>> 3. add the host to the engine
>>>> - this causes re-deploy of vdsm and deactivating the LVs
>>>> 4. start the ha-agent and ha-broker services which uses the LVs
>>>>
>>>> - I guess we could move the creation of the LVs after the vdsm is
>>>> re-deployed, just before the HE services are started, but it won't
>>>> fix the problem if the vdsm is restarted
>>>
>>> It's not going to solve our design problem, but can the users of
>>> that LV
>>> activate it just before they open it? This way there's only a small
>>> window where vdsm can crash, restart, and deactivate the LV.
>>>
>>
>> - no, it runs as vdsm user and as it seems only root can activate LVs
>> and
>> during the startup when it still has the root privs, it doesn't know
>> anything about the storage, the storage is connected on a client request
>> when it already doesn't have root privs
>
> Vdsm uses "sudo" for these purposes.
- that would solve the problem with privs, but I would really like to
avoid the situation where the vdsm disables the LVs as there is no
reason for disabling it as there can be situation where vdsm is down and
the VM with the engine is still running ok
>
>> - we could use vdsm to activate the LV if it provides API which
>> allows that
>
> There's the undocumented prepareImage(), but please do not use it before
> an ack by the storage team.
>
- sure, I'm working on it with Nir now, I won't do anything without the
storage team approval ;)
> Dan.
>
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
I'm missing something here - why doesn't VDSM knows about this LV? its a
VM started by VDSM?