[ovirt-devel] vdsm disabling logical volumes

[Saggi Mizrahi]

----- Original Message -----
> From: "Nir Soffer" <nsoffer at redhat.com>
> To: "Jiri Moskovcak" <jmoskovc at redhat.com>
> Cc: devel at ovirt.org
> Sent: Monday, May 5, 2014 1:01:12 AM
> Subject: Re: [ovirt-devel] vdsm disabling logical volumes
> 
> ----- Original Message -----
> > From: "Jiri Moskovcak" <jmoskovc at redhat.com>
> > To: "Nir Soffer" <nsoffer at redhat.com>
> > Cc: devel at 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 at redhat.com>
> > >> To: devel at 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? Is this part of the domain
> structure
> used by hosted engine, or it has nothing to do with the storage domain?
> 
> > 
> > >
> > >> 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.
> 
> > 
> > >
> > > 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?

I personally don't like people piggy backing on domains.
This kind of practice could cause other potential problems.
IMHO there needs to be a way to mark extra volumes as such so that
VDSM officially supports that kind of stuff.
> 
> Nir
> _______________________________________________
> Devel mailing list
> Devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>