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
[email protected]
http://lists.ovirt.org/mailman/listinfo/devel
