----- Original Message ----- > From: "Nir Soffer" <[email protected]> > To: "Jiri Moskovcak" <[email protected]> > Cc: [email protected] > Sent: Monday, May 5, 2014 1:01:12 AM > Subject: Re: [ovirt-devel] vdsm disabling logical volumes > > ----- Original Message ----- > > From: "Jiri Moskovcak" <[email protected]> > > To: "Nir Soffer" <[email protected]> > > Cc: [email protected] > > 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" <[email protected]> > > >> To: [email protected] > > >> 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 > [email protected] > http://lists.ovirt.org/mailman/listinfo/devel > _______________________________________________ Devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/devel
