[conspire] LVM ... PV Groups??? --> Tags! Re: VMs, qemu-kvm, ...

[Michael Paoli]

> From: "Michael Paoli" <Michael.Paoli at cal.berkeley.edu>
> Subject: VMs, qemu-kvm, ...
> Date: Thu, 20 Dec 2018 20:49:34 -0800

>   scheme, I could also create PV groups - one for real RAID-1, and one
>   for unprotected - but I've not bothered.  I do also have program I've
>   written that very quickly and easily let's me see what storage I've
>   got where - so it's easy to catch if I've put stuff I want protected
>   where it's not - or vice versa.  But I probably ought (also) set up
>   the PV groups - that would make it even easier, as I wouldn't need to
>   check/look to see which PV(s) have space - I could just name the PV
>   group when allocating the storage, and LVM would automagically find
>   storage of the desired type, without my need to check individual PVs.
>   (Sounds like such a good idea, maybe I'll get to it ... soon?)

PV *Group*?  I slightly misremembered.  The way to do that on LVM2 is
with Tags, e.g.:
(my comments on lines starting with: "// "):
LVM(8)                      System Manager's Manual                     LVM(8)
// ...
        --addtag Tag
               Add the tag Tag to a PV, VG or LV.  Supply this argument  multi-
               ple  times  to  add  more than one tag at once.  A tag is a word
               that can be  used  to  group  LVM2  objects  of  the  same  type
               together.  Tags can be given on the command line in place of PV,
               VG or LV arguments.  Tags should be prefixed  with  @  to  avoid
               ambiguity.   Each  tag  is  expanded  by  replacing  it with all
               objects possessing that tag which are of the  type  expected  by
               its  position  on  the  command line.  PVs can only possess tags
               while they are part of a Volume Group: PV tags are discarded  if
               the  PV  is  removed  from the VG.  As an example, you could tag
// ...

// Add the tags to the appropriate PVs:
# pvchange --addtag raid1 /dev/md5 && pvchange --addtag raid1 /dev/md6  
&& pvchange --addtag raid1 /dev/md7 && pvchange --addtag raid1  
/dev/md8 && pvchange --addtag raid1 /dev/md9 && pvchange --addtag  
raid1 /dev/md10 && pvchange --addtag raid1 /dev/md11 && pvchange  
--addtag raid1 /dev/md12 && pvchange --addtag unprotected /dev/md13 &&  
pvchange --addtag unprotected /dev/md15 && pvchange --addtag  
unprotected /dev/md16 && pvchange --addtag unprotected /dev/md17 &&  
pvchange --addtag unprotected /dev/md18 && pvchange --addtag  
unprotected /dev/md19 && pvchange --addtag unprotected /dev/md20; echo  
$?
// ...

// ... now we can use tag when creating (or extending) LV:
# lvcreate -l 1 -n protected tigger @raid1 2>>/dev/null
   Logical volume "protected" created.
# lvcreate -l 1 -n unprotected tigger @unprotected 2>>/dev/null
   Logical volume "unprotected" created.
# Lvs+ 2>>/dev/null | sed -ne '1p;/protected/p'
VG     LV                   LSize MiB PE Ranges
tigger protected                 4 /dev/md6:4752-4752
tigger unprotected               4 /dev/md15:2472-2472
#
// Lvs+ (and Lvs) are handy programs I wrote - notably to conveniently
// and concisely get me the LVM information I'm most commonly interested
// in.
// Let's look more closely at our underlying PVs:
# mdadm --detail /dev/md6
/dev/md6:
// ...
      Raid Level : raid1
// ...
    Raid Devices : 2
   Total Devices : 2
// ...
  Active Devices : 2
Working Devices : 2
// as we can see from above & below, protected RAID-1, 2 devices
     Number   Major   Minor   RaidDevice State
        0     253       12        0      active sync   /dev/dm-12
        1     253       13        1      active sync   /dev/dm-13
# mdadm --detail /dev/md15
/dev/md15:
// ...
      Raid Level : raid1
// ...
    Raid Devices : 1
   Total Devices : 1
// ...
  Active Devices : 1
Working Devices : 1
// as we can see from above & below, unprotected "RAID-1", only 1 device
     Number   Major   Minor   RaidDevice State
        0     253       94        0      active sync   /dev/dm-94
#

So, we see, as desired, by using the tag (rather than having to give
specific PV(s)), the LV is created on free space among the PVs of the
desired storage type.  Easy peasy, and more goof resistant than having
to remember or check which PVs are of what type and listing specific
PV(s) when creating/extending LV to get the desired type.

And, since both are in the same VG, I can change type by moving among
PV(s) from one type to another - dynamically going from unprotected to
RAID-1 or vice versa.  And, LVM 'n all that ... can dynamically grow,
or shrink (of course when shrinking any reduced size is data lost, so,
e.g., shrink the filesystem <= that size first to not lose filesystem
data - note also that most filesystem types can't be reduced in size
while mounted).