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.
- 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.
Dan.