Hi Vangelis and Neal,

we discussed it and my and Klaus' opinion is that the patch is valid. When
Ganeti manages a given VG on its own, it should check if there any orphan
LVs there. But if the administrator uses asks Ganeti to create a LV for a
particular disk in another VG, then Ganeti shouldn't manage this VG, just
use it.

  Best regards,
  Petr


On Mon, Aug 25, 2014 at 2:06 PM, Vangelis Koukis <[email protected]> wrote:

> On Fri, Aug 22, 2014 at 08:05:50pm +0200, Neal Oakey wrote:
> > Hi Klaus,
> > Hi Vangelis,
> >
> > shouldn't "--reserved-lvs" be used for this?
> > because you can use different VGs like vg_main & vg_ssd
> >
>
> Hello Neal,
>
> my understanding is that --reserved-lvs is meant for LVs *inside*
> Ganeti's set VG name. From the manpage:
>
> "The  option  --reserved-lvs  specifies  a list (comma-separated) of
> logical volume group names (regular expressions) that will be ignored by
> the
> cluster verify operation.  This is useful if the volume group used for
> Ganeti
> is shared with the system for other uses.  Note that it's not recommended
> to
> create and mark as ignored logical volume names which match Ganeti's own
> name
> format  (starting  with UUID and then .diskN), as this option only skips
> the
> verification, but not the actual use of the names given. "
>
> > And if I see this right this patch would now ignore vg_ssd (assuming
> > vg_main is the vg set via --vg-name)
> > Or am I wrong?
> >
>
> One can specify the VG to use when creating a disk, independently of the
> set VG
> name, but it's not obvious to me that this gives Ganeti the right to
> complain
> about whatever other LVs may already exist in this VG. To put it
> differently:
> If I specify vg_name in the cluster config, I'm giving full control of
> this VG
> to Ganeti, which can then complain for every LV in it which it doesn't know
> about. But if I specifically ask for a new disk to be created inside a VG,
> this
> doesn't imply that all other LVs in this VG should be handled by Ganeti.
>
> Perhaps a member of the core team can comment more extensively on this.
>
> Best regards,
> Vangelis.
>
> > Greetings
> > Neal
> >
> > Am 21.08.2014 um 16:56 schrieb 'Klaus Aehlig' via ganeti-devel:
> > > Hello Vangelis,
> > >
> > > thanks for your report. As far as I can see, your
> > > analysis is correct. Can you please...
> > >
> > >> This one-line patch against stable-2.10 fixes the problem:
> > >> $ git diff
> > >> diff --git a/lib/backend.py b/lib/backend.py
> > >> index e638e1c..3c7469c 100644
> > >> --- a/lib/backend.py
> > >> +++ b/lib/backend.py
> > >> @@ -1055,7 +1055,7 @@ def VerifyNode(what, cluster_name,
> all_hvparams):
> > >>
> > >>    if constants.NV_LVLIST in what and vm_capable:
> > >>      try:
> > >> -      val = GetVolumeList(utils.ListVolumeGroups().keys())
> > >> +      val = GetVolumeList([what[constants.NV_LVLIST]])
> > >>      except RPCFail, err:
> > >>        val = str(err)
> > >>      result[constants.NV_LVLIST] = val
> > >
> > > ...send out that patch officially?
> > >
> > > Thanks,
> > > Klaus
> > >
> > >
>

Reply via email to