7:16 a.m.
On 05/05/2014 12:01 AM, Nir Soffer wrote:
----- Original Message -----
> From: "Jiri Moskovcak" <jmoskovc(a)redhat.com>
> To: "Nir Soffer" <nsoffer(a)redhat.com>
> Cc: devel(a)ovirt.org
> Sent: Sunday, May 4, 2014 9:23:49 PM
> Subject: Re: [ovirt-devel] vdsm disabling logical volumes
>
> On 05/04/2014 07:57 PM, Nir Soffer wrote:
>> ----- Original Message -----
>>> From: "Jiri Moskovcak" <jmoskovc(a)redhat.com>
>>> To: devel(a)ovirt.org
>>> Sent: Sunday, May 4, 2014 8:08:33 PM
>>> Subject: [ovirt-devel] vdsm disabling logical volumes
>>>
>>> Greetings vdsm developers!
>>>
>>> While working on adding ISCSI support to the hosted engine tools, I ran
>>> into a problem with vdms. It seems that when stopped vdsm deactivates
>>> ALL logical volumes in it's volume group and when it starts it
>>> reactivates only specific logical volumes. This is a problem for hosted
>>> engine tools as they create logical volumes in the same volume group and
>>> when vdsm deactivates the LVs the hosted engine tools don't have a way
>>> to reactivate it, because the services drop the root permissions and are
>>> running as vdsm and apparently only root can activate LVs.
>>
>> Can you describe what volumes are you creating, and why?
>
> We create hosted-engine.lockspace (for sanlock) and
> hosted-engine.metadata (keeps data about hosted engine hosts)
Do you create these lvs in every vdsm vg?
- only in the first vg created by vdsm while deploying hosted-engine
Is this part of the domain structure
used by hosted engine, or it has nothing to do with the storage domain?
- sorry, I don't understand this question. How can I tell if it has
something to do with the storage domain? It's for storing data about
hosts set up to run the hosted-engine and data about state of engine and
the state of VM running the engine.
>
>>
>>> So far the
>>> only suitable solution seems to be to change vdsm to only
>>> deactivate/activate it's own LVs.
>>
>> This sounds reasonable. You can add a list of hosted engine lv names
>> and skip these volumes when deactivating vdsm volumes.
>
> - this sounds a bit suboptimal, vdsm already has list of it's LVs, so it
> can just disable only LVs known to it, otherwise we would have to change
> the list everytime we add some LV to the group
vdsm has a list of special lvs, that needs special treatment. Otherwise, it
consider any other lv as owned by vdsm, and will deactivate them when they are
not used.
I agree that this will create a dependency, but this can also be solved.
For example, vdsm can load the list from a file installed by hosted engine,
like the typical conf.d directories.
- ok, this is something I actually don't have strong opinion about, for
me adding a file with a list of LVs or tagging the logical volumes is
almost the same, I just need a way to tell vdsm which LVs to ignore..
>
>>
>> Another solution is to tag hosted engine lvs, and have vdsm ignore
>> lvs that contains this tag.
>
> - this sounds good, because if we teach vdsm to ignore LVs with some tag
> we can add new LVs in future without changing vdsm. This however applies
> also to the solution where vdsm only disables it's own LVs,
vdsm own lvs are *all* lvs in vdsm vgs. We can implement something like this
using some historic tags we keep (e.g. RHAT_*), but I'd rather add new tag with
clear semantic than use some random historic value we have.
> so it
> depends on vdsm devels which solution they find better. I think the
> solution without tags is better, because is simpler and others (like
> hosted-engine) can just createlv and don't bother with tags..
I think that a generic tag like OVIRT_IGNORE is an easy solution for everyone.
Federico, what do you think?
Nir