Re: [ovirt-devel] vdsm disabling logical volumes

From: "Jiri Moskovcak" <jmoskovc(a)redhat.com&gt; To: "Nir Soffer" <nsoffer(a)redhat.com&gt; Cc: devel(a)ovirt.org, "Federico Simoncelli" <fsimonce(a)redhat.com&gt;, "Allon Mureinik" <amureini(a)redhat.com&gt;, "Greg Padgett" <gpadgett(a)redhat.com&gt; Sent: Monday, May 5, 2014 3:16:37 PM Subject: Re: [ovirt-devel] vdsm disabling logical volumes On 05/05/2014 12:01 AM, Nir Soffer wrote: > ----- Original Message ----- >> From: "Jiri Moskovcak" <jmoskovc(a)redhat.com&gt; >> To: "Nir Soffer" <nsoffer(a)redhat.com&gt; >> 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&gt; >>>> 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 >