Provided by: lvm2-lockd_2.02.176-4.1ubuntu3_amd64 bug

NAME

       lvmlockd — LVM locking daemon

DESCRIPTION

       LVM commands use lvmlockd to coordinate access to shared storage.
       When LVM is used on devices shared by multiple hosts, locks will:

       · coordinate reading and writing of LVM metadata
       · validate caching of LVM metadata
       · prevent concurrent activation of logical volumes

       lvmlockd uses an external lock manager to perform basic locking.
       Lock manager (lock type) options are:

       · sanlock: places locks on disk within LVM storage.
       · dlm: uses network communication and a cluster manager.

OPTIONS

       lvmlockd [options]

       For default settings, see lvmlockd -h.

       --help | -h
               Show this help information.

       --version | -V
               Show version of lvmlockd.

       --test | -T
               Test mode, do not call lock manager.

       --foreground | -f
               Don't fork.

       --daemon-debug | -D
               Don't fork and print debugging to stdout.

       --pid-file | -p path
               Set path to the pid file.

       --socket-path | -s path
               Set path to the socket to listen on.

       --syslog-priority | -S err|warning|debug
               Write log messages from this level up to syslog.

       --gl-type | -g sanlock|dlm
               Set global lock type to be sanlock or dlm.

       --host-id | -i num
               Set the local sanlock host id.

       --host-id-file | -F path
               A file containing the local sanlock host_id.

       --sanlock-timeout | -o seconds
               Override the default sanlock I/O timeout.

       --adopt | -A 0|1
               Adopt locks from a previous instance of lvmlockd.

USAGE

   Initial set up
       Using LVM with lvmlockd for the first time includes some one-time set up steps:

   1. choose a lock manager
       dlm
       If  dlm  (or  corosync) are already being used by other cluster software, then select dlm.
       dlm uses corosync which  requires  additional  configuration  beyond  the  scope  of  this
       document.  See corosync and dlm documentation for instructions on configuration, setup and
       usage.

       sanlock
       Choose sanlock if dlm/corosync are not otherwise required.  sanlock does not depend on any
       clustering software or configuration.

   2. configure hosts to use lvmlockd
       On all hosts running lvmlockd, configure lvm.conf:
       locking_type = 1
       use_lvmlockd = 1

       sanlock
       Assign each host a unique host_id in the range 1-2000 by setting
       /etc/lvm/lvmlocal.conf local/host_id

   3. start lvmlockd
       Use a unit/init file, or run the lvmlockd daemon directly:
       systemctl start lvm2-lvmlockd

   4. start lock manager
       sanlock
       Use unit/init files, or start wdmd and sanlock daemons directly:
       systemctl start wdmd sanlock

       dlm
       Follow external clustering documentation when applicable, or use unit/init files:
       systemctl start corosync dlm

   5. create VG on shared devices
       vgcreate --shared <vgname> <devices>

       The  shared option sets the VG lock type to sanlock or dlm depending on which lock manager
       is running.  LVM commands will perform locking for the VG using lvmlockd.   lvmlockd  will
       use the chosen lock manager.

   6. start VG on all hosts
       vgchange --lock-start

       lvmlockd  requires  shared VGs to be started before they are used.  This is a lock manager
       operation to start (join) the VG lockspace, and it may take some time.   Until  the  start
       completes,  locks  for  the VG are not available.  LVM commands are allowed to read the VG
       while start is in progress.  (A unit/init file can also be used to start VGs.)

   7. create and activate LVs
       Standard lvcreate and lvchange commands are used to create and activate LVs  in  a  shared
       VG.

       An  LV  activated  exclusively  on one host cannot be activated on another.  When multiple
       hosts need to use the same LV concurrently, the LV can be activated  with  a  shared  lock
       (see  lvchange  options  -aey vs -asy.)  (Shared locks are disallowed for certain LV types
       that cannot be used from multiple hosts.)

   Normal start up and shut down
       After initial set up, start up and shut down include the following  general  steps.   They
       can be performed manually or using the system service manager.

       · start lvmetad
       · start lvmlockd
       · start lock manager
       · vgchange --lock-start
       · activate LVs in shared VGs

       The shut down sequence is the reverse:

       · deactivate LVs in shared VGs
       · vgchange --lock-stop
       · stop lock manager
       · stop lvmlockd
       · stop lvmetad

TOPICS

   VG access control
       The following terms are used to describe different forms of VG access control.

       lockd VG

       A  "lockd  VG" is a shared VG that has a "lock type" of dlm or sanlock.  Using it requires
       lvmlockd.  These VGs exist on shared storage that  is  visible  to  multiple  hosts.   LVM
       commands use lvmlockd to perform locking for these VGs when they are used.

       If  the  lock  manager  for  the  lock type is not available (e.g. not started or failed),
       lvmlockd is unable to acquire locks for LVM commands.  LVM commands that only read the  VG
       will  generally  be  allowed  to  continue  without  locks  in this case (with a warning).
       Commands to modify or activate the VG will fail without the necessary locks.

       local VG

       A "local VG" is meant to be used by a single host.  It has  no  lock  type  or  lock  type
       "none".   LVM  commands  and  lvmlockd  do  not perform locking for these VGs.  A local VG
       typically exists on local (non-shared)  devices  and  cannot  be  used  concurrently  from
       different hosts.

       If  a local VG does exist on shared devices, it should be owned by a single host by having
       its system ID set, see lvmsystemid(7).  Only the host with a matching system  ID  can  use
       the local VG.  A VG with no lock type and no system ID should be excluded from all but one
       host using lvm.conf filters.  Without any of these  protections,  a  local  VG  on  shared
       devices can be easily damaged or destroyed.

       clvm VG

       A  "clvm  VG"  is  a  VG  on  shared  storage  (like  a  lockd VG) that requires clvmd for
       clustering.  See below for converting a clvm VG to a lockd VG.

   lockd VGs from hosts not using lvmlockd
       Only hosts that use lockd VGs should be  configured  to  run  lvmlockd.   However,  shared
       devices  in lockd VGs may be visible from hosts not using lvmlockd.  From a host not using
       lvmlockd, lockd VGs are ignored in the same way as foreign VGs (see lvmsystemid(7).)

       The --shared option for reporting and display commands causes lockd VGs to be displayed on
       a host not using lvmlockd, like the --foreign option does for foreign VGs.

   vgcreate comparison
       The  type  of VG access control is specified in the vgcreate command.  See vgcreate(8) for
       all vgcreate options.

       vgcreate <vgname> <devices>

       · Creates a local VG with the local host's system ID when neither lvmlockd  nor  clvm  are
         configured.

       · Creates a local VG with the local host's system ID when lvmlockd is configured.

       · Creates a clvm VG when clvm is configured.

       vgcreate --shared <vgname> <devices>

       · Requires lvmlockd to be configured and running.

       · Creates  a  lockd  VG  with  lock  type  sanlock|dlm  depending on which lock manager is
         running.

       · LVM commands request locks from lvmlockd to use the VG.

       · lvmlockd obtains locks from the selected lock manager.

       vgcreate -c--clustered y <vgname> <devices>

       · Requires clvm to be configured and running.

       · Creates a clvm VG with the "clustered" flag.

       · LVM commands request locks from clvmd to use the VG.

   creating the first sanlock VG
       Creating the first sanlock VG  is  not  protected  by  locking,  so  it  requires  special
       attention.   This is because sanlock locks exist on storage within the VG, so they are not
       available until the VG exists.  The first sanlock VG created  will  automatically  contain
       the "global lock".  Be aware of the following special considerations:

       · The  first vgcreate command needs to be given the path to a device that has not yet been
         initialized with pvcreate.  The pvcreate initialization will be done by vgcreate.   This
         is  because  the  pvcreate command requires the global lock, which will not be available
         until after the first sanlock VG is created.

       · Because the first sanlock VG  will  contain  the  global  lock,  this  VG  needs  to  be
         accessible  to  all  hosts that will use sanlock shared VGs.  All hosts will need to use
         the global lock from the first sanlock VG.

       · While running vgcreate for the first sanlock VG, ensure that the device  being  used  is
         not  used  by another LVM command.  Allocation of shared devices is usually protected by
         the global lock, but this cannot be done for the first sanlock VG which  will  hold  the
         global lock.

       · While  running  vgcreate for the first sanlock VG, ensure that the VG name being used is
         not used by another LVM command.  Uniqueness of VG  names  is  usually  ensured  by  the
         global lock.

         See below for more information about managing the sanlock global lock.

   using lockd VGs
       There are some special considerations when using lockd VGs.

       When  use_lvmlockd is first enabled in lvm.conf, and before the first lockd VG is created,
       no global lock will exist.  In this initial state, LVM commands try and  fail  to  acquire
       the  global  lock,  producing a warning, and some commands are disallowed.  Once the first
       lockd VG is created, the global lock will be available, and LVM will be fully operational.

       When a new lockd VG is created, its lockspace is automatically started on  the  host  that
       creates  it.   Other  hosts need to run 'vgchange --lock-start' to start the new VG before
       they can use it.

       From the 'vgs' command, lockd VGs are indicated by "s" (for  shared)  in  the  sixth  attr
       field.   The  specific  lock  type and lock args for a lockd VG can be displayed with 'vgs
       -o+locktype,lockargs'.

       lockd VGs need to be "started"  and  "stopped",  unlike  other  types  of  VGs.   See  the
       following section for a full description of starting and stopping.

       vgremove  of  a  lockd  VG  will  fail  if  other hosts have the VG started.  Run vgchange
       --lock-stop <vgname> on all other hosts before vgremove.  (It  may  take  several  seconds
       before vgremove recognizes that all hosts have stopped a sanlock VG.)

   starting and stopping VGs
       Starting  a  lockd  VG (vgchange --lock-start) causes the lock manager to start (join) the
       lockspace for the VG on the host where it is run.  This makes locks for the  VG  available
       to  LVM commands on the host.  Before a VG is started, only LVM commands that read/display
       the VG are allowed to continue without locks (and with a warning).

       Stopping a lockd VG (vgchange --lock-stop) causes the lock manager  to  stop  (leave)  the
       lockspace  for  the  VG  on  the  host  where  it  is  run.   This  makes locks for the VG
       inaccessible to the host.  A VG cannot be stopped while it has active LVs.

       When using the lock type sanlock, starting a VG can take a long time (potentially  minutes
       if the host was previously shut down without cleanly stopping the VG.)

       A lockd VG can be started after all the following are true:
       · lvmlockd is running
       · the lock manager is running
       · the VG's devices are visible on the system

       A lockd VG can be stopped if all LVs are deactivated.

       All lockd VGs can be started/stopped using:
       vgchange --lock-start
       vgchange --lock-stop

       Individual VGs can be started/stopped using:
       vgchange --lock-start <vgname> ...
       vgchange --lock-stop <vgname> ...

       To make vgchange not wait for start to complete:
       vgchange --lock-start --lock-opt nowait ...

       lvmlockd can be asked directly to stop all lockspaces:
       lvmlockctl --stop-lockspaces

       To  start  only  selected  lockd  VGs,  use the lvm.conf activation/lock_start_list.  When
       defined, only VG names in this list are started by vgchange.  If the list is  not  defined
       (the  default), all visible lockd VGs are started.  To start only "vg1", use the following
       lvm.conf configuration:

       activation {
           lock_start_list = [ "vg1" ]
           ...
       }

   automatic starting and automatic activation
       When system-level scripts/programs automatically start VGs, they  should  use  the  "auto"
       option.  This option indicates that the command is being run automatically by the system:

       vgchange --lock-start --lock-opt auto [<vgname> ...]

       The     "auto"     option     causes     the    command    to    follow    the    lvm.conf
       activation/auto_lock_start_list.   If  auto_lock_start_list  is  undefined,  all  VGs  are
       started, just as if the auto option was not used.

       When auto_lock_start_list is defined, it lists the lockd VGs that should be started by the
       auto command.  VG names that do not match an item in the list will be ignored by the  auto
       start command.

       (The  lock_start_list  is also still used to filter VG names from all start commands, i.e.
       with or without the auto option.  When the lock_start_list is defined, only VGs matching a
       list item can be started with vgchange.)

       The  auto_lock_start_list  allows  a  user  to  select  certain  lockd  VGs that should be
       automatically started by the system (or indirectly, those that should not).

       To use auto activation of lockd LVs (see auto_activation_volume_list),  auto  starting  of
       the corresponding lockd VGs is necessary.

   internal command locking
       To  optimize  the  use of LVM with lvmlockd, be aware of the three kinds of locks and when
       they are used:

       GL lock

       The global lock (GL lock) is associated with global information, which is information  not
       isolated to a single VG.  This includes:

       · The global VG namespace.
       · The set of orphan PVs and unused devices.
       · The properties of orphan PVs, e.g. PV size.

       The  global  lock is acquired in shared mode by commands that read this information, or in
       exclusive mode by commands that change it.  For example, the command  'vgs'  acquires  the
       global  lock  in shared mode because it reports the list of all VG names, and the vgcreate
       command acquires the global lock in exclusive mode because it creates a new VG  name,  and
       it takes a PV from the list of unused PVs.

       When an LVM command is given a tag argument, or uses select, it must read all VGs to match
       the tag or selection, which causes the global lock to be acquired.

       VG lock

       A VG lock is associated with each lockd VG.  The VG lock is acquired  in  shared  mode  to
       read  the  VG and in exclusive mode to change the VG (modify the VG metadata or activating
       LVs).  This lock serializes access to a VG with all other LVM commands  accessing  the  VG
       from all hosts.

       The  command 'vgs' will not only acquire the GL lock to read the list of all VG names, but
       will acquire the VG lock for each VG prior to reading it.

       The command 'vgs <vgname>' does not acquire the GL lock (it does not need the list of  all
       VG names), but will acquire the VG lock on each VG name argument.

       LV lock

       An  LV  lock  is  acquired  before  the  LV  is activated, and is released after the LV is
       deactivated.  If the LV lock cannot be acquired, the LV is not activated.   LV  locks  are
       persistent  and  remain in place when the activation command is done.  GL and VG locks are
       transient, and are held only while an LVM command is running.

       lock retries

       If a request for a GL or VG lock fails due to a lock conflict with another host,  lvmlockd
       automatically  retries for a short time before returning a failure to the LVM command.  If
       those retries are insufficient, the LVM command will  retry  the  entire  lock  request  a
       number  of  times  specified by global/lvmlockd_lock_retries before failing.  If a request
       for an LV lock fails due to a lock conflict, the command fails immediately.

   managing the global lock in sanlock VGs
       The global lock exists in one of the sanlock VGs.   The  first  sanlock  VG  created  will
       contain  the  global lock.  Subsequent sanlock VGs will each contain disabled global locks
       that can be enabled later if necessary.

       The VG containing the global lock must be visible to all hosts using  sanlock  VGs.   This
       can  be a reason to create a small sanlock VG, visible to all hosts, and dedicated to just
       holding the global lock.  While not required, this strategy can help to  avoid  difficulty
       in the future if VGs are moved or removed.

       The  vgcreate  command  typically  acquires  the global lock, but in the case of the first
       sanlock VG, there will be no global lock to acquire until the first vgcreate is  complete.
       So, creating the first sanlock VG is a special case that skips the global lock.

       vgcreate  for a sanlock VG determines it is the first one to exist if no other sanlock VGs
       are visible.  It is possible that other sanlock VGs do exist but are not  visible  on  the
       host  running  vgcreate.   In  this  case, vgcreate would create a new sanlock VG with the
       global lock enabled.  When the other VG containing a global lock  appears,  lvmlockd  will
       see  more  than one VG with a global lock enabled, and LVM commands will report that there
       are duplicate global locks.

       If the situation arises where more than one sanlock VG contains a global lock, the  global
       lock should be manually disabled in all but one of them with the command:

       lvmlockctl --gl-disable <vgname>

       (The one VG with the global lock enabled must be visible to all hosts.)

       An opposite problem can occur if the VG holding the global lock is removed.  In this case,
       no global lock will exist following the vgremove, and subsequent LVM commands will fail to
       acquire  it.   In  this  case,  the global lock needs to be manually enabled in one of the
       remaining sanlock VGs with the command:

       lvmlockctl --gl-enable <vgname>

       A small sanlock VG dedicated to holding the global lock can avoid the case  where  the  GL
       lock must be manually enabled after a vgremove.

   internal lvmlock LV
       A sanlock VG contains a hidden LV called "lvmlock" that holds the sanlock locks.  vgreduce
       cannot yet remove the PV holding the lvmlock LV.  To remove this PV, change  the  VG  lock
       type  to "none", run vgreduce, then change the VG lock type back to "sanlock".  Similarly,
       pvmove cannot be used on a PV used by the lvmlock LV.

       To place the lvmlock LV on a specific device, create the VG with only  that  device,  then
       use vgextend to add other devices.

   LV activation
       In  a  shared  VG,  activation changes involve locking through lvmlockd, and the following
       values are possible with lvchange/vgchange -a:

       y|ey   The command activates the LV in exclusive mode, allowing a single host to  activate
              the  LV.   Before  activating  the  LV,  the  command  uses  lvmlockd to acquire an
              exclusive lock on the LV.  If the lock cannot be acquired, the LV is not  activated
              and an error is reported.  This would happen if the LV is active on another host.

       sy     The  command  activates  the LV in shared mode, allowing multiple hosts to activate
              the LV concurrently.  Before activating  the  LV,  the  command  uses  lvmlockd  to
              acquire  a  shared  lock  on the LV.  If the lock cannot be acquired, the LV is not
              activated and an error is  reported.   This  would  happen  if  the  LV  is  active
              exclusively  on  another  host.   If the LV type prohibits shared access, such as a
              snapshot, the command will report an error and fail.  The shared mode  is  intended
              for  a multi-host/cluster application or file system.  LV types that cannot be used
              concurrently from multiple hosts include thin, cache, raid, and snapshot.  lvextend
              on  LV  with  shared  locks  is  not  yet  allowed.  The LV must be deactivated, or
              activated exclusively to run lvextend.  (LVs with the mirror type can be  activated
              in shared mode from multiple hosts when using the dlm lock type and cmirrord.)

       n      The  command  deactivates  the  LV.   After  deactivating  the LV, the command uses
              lvmlockd to release the current lock on the LV.

   manually repairing a shared VG
       Some failure conditions may not be repairable while the VG has a  shared  lock  type.   In
       these  cases,  it  may  be possible to repair the VG by forcibly changing the lock type to
       "none".  This is done by adding "--lock-opt force" to the normal command for changing  the
       lock  type: vgchange --lock-type none VG.  The VG lockspace should first be stopped on all
       hosts, and be certain that no hosts are using the VG before this is done.

   recover from lost PV holding sanlock locks
       In a sanlock VG, the sanlock locks are held on the hidden "lvmlock" LV.  If the PV holding
       this  LV  is  lost, a new lvmlock LV needs to be created.  To do this, ensure no hosts are
       using the VG, then forcibly change the lock type to "none" (see above).  Then  change  the
       lock  type back to "sanlock" with the normal command for changing the lock type:  vgchange
       --lock-type sanlock VG.  This recreates the internal lvmlock LV with the necessary locks.

   locking system failures
       lvmlockd failure

       If lvmlockd fails or is killed while holding locks, the locks are  orphaned  in  the  lock
       manager.  lvmlockd can be restarted with an option to adopt locks in the lock manager that
       had been held by the previous instance.

       dlm/corosync failure

       If dlm or corosync fail, the  clustering  system  will  fence  the  host  using  a  method
       configured within the dlm/corosync clustering environment.

       LVM  commands  on  other  hosts  will  be  blocked  from  acquiring  any  locks  until the
       dlm/corosync recovery process is complete.

       sanlock lease storage failure

       If the PV under a sanlock VG's lvmlock LV  is  disconnected,  unresponsive  or  too  slow,
       sanlock  cannot  renew  the  lease  for  the  VG's locks.  After some time, the lease will
       expire, and locks that the host owns in the VG can be acquired by  other  hosts.   The  VG
       must  be  forcibly  deactivated on the host with the expiring lease before other hosts can
       acquire its locks.

       When the sanlock daemon detects that the lease  storage  is  lost,  it  runs  the  command
       lvmlockctl  --kill  <vgname>.   This  command  emits  a  syslog message stating that lease
       storage is lost for the VG and LVs must be immediately deactivated.

       If no LVs are active in the VG, then the lockspace with an expiring lease will be removed,
       and  errors will be reported when trying to use the VG.  Use the lvmlockctl --drop command
       to clear the stale lockspace from lvmlockd.

       If the VG has active LVs  when  the  lock  storage  is  lost,  the  LVs  must  be  quickly
       deactivated  before  the  lockspace  lease  expires.   After  all LVs are deactivated, run
       lvmlockctl --drop <vgname> to clear the expiring lockspace from lvmlockd.  If all  LVs  in
       the  VG are not deactivated within about 40 seconds, sanlock will reset the host using the
       local watchdog.  The machine reset is effectively a  severe  form  of  "deactivating"  LVs
       before they can be activated on other hosts.  The reset is considered a better alternative
       than having LVs used by multiple hosts at once, which could easily damage or destroy their
       content.

       In  the  future,  the  lvmlockctl  kill  command  may  automatically  attempt  to forcibly
       deactivate LVs before the sanlock lease expires.  Until then, the  user  must  notice  the
       syslog message and manually deactivate the VG before sanlock resets the machine.

       sanlock daemon failure

       If the sanlock daemon fails or exits while a lockspace is started, the local watchdog will
       reset the host.  This is necessary to protect any application  resources  that  depend  on
       sanlock leases which will be lost without sanlock running.

   changing dlm cluster name
       When  a dlm VG is created, the cluster name is saved in the VG metadata.  To use the VG, a
       host must be in the named dlm cluster.  If the dlm cluster name  changes,  or  the  VG  is
       moved to a new cluster, the dlm cluster name saved in the VG must also be changed.

       To see the dlm cluster name saved in the VG, use the command:
       vgs -o+locktype,lockargs <vgname>

       To  change  the  dlm  cluster  name  in  the  VG when the VG is still used by the original
       cluster:

       · Stop the VG on all hosts:
         vgchange --lock-stop <vgname>

       · Change the VG lock type to none:
         vgchange --lock-type none <vgname>

       · Change the dlm cluster name on the host or move the VG to the new cluster.  The new  dlm
         cluster must now be active on the host.  Verify the new name by:
         cat /sys/kernel/config/dlm/cluster/cluster_name

       · Change the VG lock type back to dlm which sets the new cluster name:
         vgchange --lock-type dlm <vgname>

       · Start the VG on hosts to use it:
         vgchange --lock-start <vgname>

       To change the dlm cluster name in the VG when the dlm cluster name has already changed, or
       the VG has already moved to a different cluster:

       · Ensure the VG is not being used by any hosts.

       · The new dlm cluster must be active on the host  making  the  change.   The  current  dlm
         cluster name can be seen by:
         cat /sys/kernel/config/dlm/cluster/cluster_name

       · Change the VG lock type to none:
         vgchange --lock-type none --lock-opt force <vgname>

       · Change the VG lock type back to dlm which sets the new cluster name:
         vgchange --lock-type dlm <vgname>

       · Start the VG on hosts to use it:
         vgchange --lock-start <vgname>

   changing a local VG to a lockd VG
       All LVs must be inactive to change the lock type.

       lvmlockd must be configured and running as described in USAGE.

       Change a local VG to a lockd VG with the command:
       vgchange --lock-type sanlock|dlm <vgname>

       Start the VG on hosts to use it:
       vgchange --lock-start <vgname>

   changing a lockd VG to a local VG
       Stop the lockd VG on all hosts, then run:
       vgchange --lock-type none <vgname>

       To change a VG from one lockd type to another (i.e. between sanlock and dlm), first change
       it to a local VG, then to the new type.

   changing a clvm VG to a lockd VG
       All LVs must be inactive to change the lock type.

       First change the clvm VG to a local VG.  Within a running clvm cluster, change a  clvm  VG
       to a local VG with the command:

       vgchange -cn <vgname>

       If  the  clvm cluster is no longer running on any nodes, then extra options can be used to
       forcibly make the VG local.  Caution: this is only safe if all nodes  have  stopped  using
       the VG:

       vgchange --config 'global/locking_type=0 global/use_lvmlockd=0'
              -cn <vgname>

       After the VG is local, follow the steps described in "changing a local VG to a lockd VG".

   limitations of lockd VGs
       Things that do not yet work in lockd VGs:
       · creating a new thin pool and a new thin LV in a single command
       · using lvcreate to create cache pools or cache LVs (use lvconvert)
       · using external origins for thin LVs
       · splitting mirrors and snapshots from LVs
       · pvmove of entire PVs, or under LVs activated with shared locks
       · vgsplit
       · vgmerge
       · resizing an LV that is active in the shared mode on multiple hosts

   lvmlockd changes from clvmd
       (See above for converting an existing clvm VG to a lockd VG.)

       While  lvmlockd  and  clvmd  are  entirely  different  systems,  LVM command usage remains
       similar.  Differences are more notable when using lvmlockd's sanlock option.

       Visible usage differences between lockd VGs (using lvmlockd) and clvm VGs (using clvmd):

       · lvm.conf  must  be  configured  to  use  either  lvmlockd  (use_lvmlockd=1)   or   clvmd
         (locking_type=3), but not both.

       · vgcreate --shared creates a lockd VG, and vgcreate --clustered y creates a clvm VG.

       · lvmlockd  adds  the  option  of using sanlock for locking, avoiding the need for network
         clustering.

       · lvmlockd defaults to the exclusive activation  mode  whenever  the  activation  mode  is
         unspecified, i.e. -ay means -aey, not -asy.

       · lvmlockd  commands  always apply to the local host, and never have an effect on a remote
         host.  (The activation option 'l' is not used.)

       · lvmlockd works with thin and cache pools and LVs.

       · lvmlockd works with lvmetad.

       · lvmlockd saves the cluster name for a lockd VG using dlm.  Only hosts  in  the  matching
         cluster can use the VG.

       · lvmlockd   requires   starting/stopping   lockd   VGs  with  vgchange  --lock-start  and
         --lock-stop.

       · vgremove of a sanlock VG may fail indicating that all hosts  have  not  stopped  the  VG
         lockspace.  Stop the VG on all hosts using vgchange --lock-stop.

       · vgreduce  or pvmove of a PV in a sanlock VG will fail if it holds the internal "lvmlock"
         LV that holds the sanlock locks.

       · lvmlockd uses lock retries instead of lock queueing, so high lock contention may require
         increasing global/lvmlockd_lock_retries to avoid transient lock failures.

       · lvmlockd  includes VG reporting options lock_type and lock_args, and LV reporting option
         lock_args to view the corresponding metadata fields.

       · In the 'vgs' command's sixth VG attr field, "s" for "shared" is displayed for lockd VGs.

       · If lvmlockd fails or is killed while in use, locks it held remain but  are  orphaned  in
         the  lock  manager.   lvmlockd can be restarted with an option to adopt the orphan locks
         from the previous instance of lvmlockd.