tools: add 'lvm lastlog' command for interactive query and display of last command's log

If we're running in lvm shell, we can keep last command's log report
for further query with possible different selection criteria for easy
log lookup.

refactor: move 'interactive' field from struct command_line to struct cmd_context as 'is_interactive' switch

log: annotate processing code with report_current_object_cmdlog

log: annotate processing code with log_set_report_{context,object_type,id_and_name}

report: add 'multiple_output' arg to report_init

Some reports may be reported several times with possible different
selection criteria, just like command log report.

libdm: report: add dm_report_set_selection

Since we can do repeated dm_report_output calls now, we also like
to be able to set selection for each of these outputs.

libdm: report: add DM_REPORT_OUTPUT_MULTIPLE_TIMES report flag to keep report data even after output is done

The DM_REPORT_OUTPUT_MULTIPLE_TIMES instructs reporting code to
keep rows even after dm_report_output call - the rows are not
destroyed in this case which makes it possible to call dm_report_output
multiple times.

refactor: move field width calculation and sort preparation from _do_report_object to dm_report_output

This also prepares code for repeated dm_report_output calls.

libdm: report: remember special field to display selection status in struct row's field_sel_status variable

This allows for moving parts of the code from dm_report_object to
dm_report_output which is important for subsequent patches that allow
for repeated dm_report_output, not destroying rows on each
dm_report_output call.

log: also pass log_print through report and add log_print_bypass_report for use in libdm-report for direct print without report

log_print is used during cmd line processing to log the result of the
operation (e.g. "Volume group vg successfully changed" and similar).

We don't want output from log_print to be interleaved with current
reports from group where log is reported as well. Also, the information
printed by log_print belongs to the log report too, so it should be
rerouted to log report if it's set.

Since the code in libdm-report which is responsible for doing the report
output uses log_print too, we need to use a different kind of log_print
which bypasses any log report currently used for logging (...simply,
we can't call log_print to output the log report itself which in turn
would again reroute to report - the report would never get on output
this way).

report: add report_current_object_cmdlog fn as a shortcut for reporting current object's log item

log: log warnings and errors via report if set; add log_set_report* fns

This patch adds structures and functions to reroute error and warning
logs to log report, if it's set.

There are 5 new functions:
  - log_set_report
    Set log report where logging will be rerouted.

  - log_set_report_context
    Set context globally so any report_cmdlog call will use it.

  - log_set_report_object_type
    Set object type globally so any report_cmdlog call will use it.

  - log_set_report_object_name_and_id
    Set object ID and name globally so any report_cmdlog call will use it.

  - log_set_report_object_group_and_group_id
    Set object group ID and name globally so any report_cmdlog call will use it.

These functions will be called during LVM command processing so any logs
which are rerouted to log report contain proper information about current
processing state.

toollib: make it possible to also process internal VGs, add 'include_internal' switch to process_each_vg fn

The lvm fullreport works per VG and as such, the vg, lv, pv, seg and
pvseg subreport is done for each VG. However, if the PV is not part of
any VG yet, we still want to display pv and pvseg subreports for these
"orphan" PVs - so enable this for lvm fullreport's process_each_vg call.

report: check report type and options used for full report's subreports

If we have fullreport, make sure that the options/sort keys used for
each report doesn't change its type - we want to preserve the original
type so it's always 5 different subreports within fullreport (vg, lv, pv,
seg, pvseg). Since we have all report types within fullreport, users
should add fields under proper subreport type - this minimizes
duplication of info displayed on output.

report: recognize selection (-S|--select) for each subreport; make -S|--select groupable

report: recognize list of keys to sort report by (-O|--sort) for each subreport; make -O|--sort groupable

report: recognize list of fields to report (-o|--options) for each subreport

report: add _get_report_idx_from_name and _should_process_report_idx helper fns

Prepare for recognition of cmd line options for each subreport within
one command.

args: add --configreport arg

args: add priorities for grouping args

Groupable args (the ones marked with ARG_GROUPABLE flag) start a new
group of args if:
  - this is the first time we hit such a groupable arg,
  - or if non-countable arg is repeated.

However, there may be cases where we want to give priorities when
forming groups and hence force new group creation if we hit an arg
with higher grouping priority.

For example, let's assume (for now) hypothetical sequence of args used:

  lvs -o lv_name --configreport log -o log_type --configreport lv -o +vg_name

Without giving any priorites, we end up with:

  lvs -o lv_name --configreport log -o log_type --configreport lv -o +vg_name
     |                            | |                           | |          |
     \__________GROUP1___________/   \________GROUP2___________/   \_GROUP3_/

This is because we hit "-o" as the first groupable arg. The --configreport,
even though it's groupable too, it falls into the previous "-o" group.

While we may need to give priority to the --configreport arg that should
always start a new group in this scenario instead:

  lvs -o lv_name --configreport log -o log_type --configreport lv -o +vg_name
      |         | |                            | |                           |
      \_GROUP1_/   \_________GROUP2___________/   \_________GROUP3__________/

So here "-o" started a new group but since "--configreport" has higher
priority than "-o", it starts fresh new group now and hence the rest of
the command line's args are grouped by --configreport now.

conf: add report/{vgs,pvs,lvs,pvsegs,segs}_{cols,sort}_full config settings

commands: report: add lvm fullreport command

lvm fullreport executes 5 subreports (vg, pv, lv, pvseg, seg) per each VG
(and so taking one VG lock each time) within one command which makes it
easier to produce full report about LVM entities.

Since all 5 subreports for a VG are done under a VG lock, the output is
more consistent mainly in cases where LVM entities may be changed in
parallel.

commands: recognize --reportformat option for other commands

Enables --reportformat option for all command using processing_handle
(and process_each_* fn variant), that is: lvchange, lvcreate, lvdisplay,
lvextend, lvreduce, lvremove, lvrename, lvresize, lvscan, pvchange,
pvresize, pvcreate, pvdisplay, pvmove, pvremove, pvscan, vgcfgbackup,
vgchange, vgck, vgconvert, vgcreate, vgdisplay, vgexport, vgextend,
vgimport, vgmknodes, vgreduce, vgremove, vgrename command.

commands: recognize --reportformat option for pvs,vgs,lvs and devtypes command

Enables --reportformat options for pvs, vgs, lvs, devtypes command.

report: add current report to existing group

Add any report (pvs/vgs/lvs) currently processed to current report group
which is part of processing handle and which already contains log
report. This way both log report and pvs/vgs/lvs report will be
reported as a whole within a group, thus having same output format as
selected by --reportformat option.

toollib: add 'parent' field to processing_handle; init report format only if there's no parent

If there's parent processing handle, we don't need to create completely
new report group and status report - we'll just reuse the one already
initialized for the parent.

Currently, the situation where this matter is when doing internal report
to do the selection for processing commands where we have parent processing
handle for the command itself and processing handle for the selection
part (that is selection for non-reporting tools).

toollib: add report_group and log_rh to processing_handle and initialize cmd processing log report

Wire up report group creation with log report in struct
processing_handle and call report_format_init during processing handle
initialization (init_processing_handle fn) and destroy it while
destroing processing handle (destroy_processing_handle fn).

This way, all the LVM command processing using processing handle
has access to log report via which the current command log
can be reported as items are processed.

report: separate common report and per-report args

Separating common report and per-report arguments prepares the code for
handling several reports per one command (for example, the command log
report and LVM command report itself).

Each report can have sort keys, options (fields), list of fields to
compact and selection criteria set individually. Hooks for setting these
per report within one command will be a part of subsequent patches, this
patch only separates new struct single_report_args out of existing
struct report_args.

conf: add log/report_command_log config setting

conf: add report/output_format config setting

New report/output_format configuration sets the output format used
for all LVM commands globally. Currently, there are 2 formats
recognized:
   - basic (the classical basic output with columns and rows, used by default)
   - json (output is in json format)

toollib: add report_format_init fn to create report group and to create/add log report handle

Add new --reportformat option and new report_format_init function that
checks this option and creates new report group accordingly, also
preparing log report handle and adding it to the report group just
created.

conf: add log/command_log_{sort,cols} config settings

report: add CMDLOG report type

This is a preparation for new CMDLOG report type which is going to be
used for reporting LVM command log.

The new report type introduces several new fields (log_seq_num, log_type,
log_context, log_object_type, log_object_group, log_object_id, object_name,
log_message, log_errno, log_ret_code) as well as new configuration settings
to set this report type (report/command_log_sort and report/command_log_cols
lvm.conf settings).

This patch also introduces internal report_cmdlog helper function
which is a wrapper over dm_report_object to report command log via
CMDLOG report type and which is going to be used throughout the code
to report the log items.

libdm: report: implement DM_REPORT_GROUP_JSON for JSON report output

This patch introduces DM_REPORT_GROUP_JSON report group type. When using
this group type and when pushing a report to such a group, these flags
are automatically unset:

   DM_REPORT_OUTPUT_ALIGNED
   DM_REPORT_OUTPUT_HEADINGS
   DM_REPORT_OUTPUT_COLUMNS_AS_ROWS

...and this flag is set:

   DM_REPORT_OUTPUT_BUFFERED

The whole group is encapsulated in { } for the outermost JSON object
and then each report is reported on output as array of objects where
each object is the row from report:

  {
     "report_name1": [
         {field1="value", field2="value",...},
         {field1="value", field2="value",...}
         ...
     ],
     "report_name2": [
         {field1="value", field2="value",...},
         {field1="value", field2="value",...}
         ...
     ]
     ...
  }

libdm: report: implement DM_REPORT_GROUP_BASIC for extended report output

This patch introduces DM_REPORT_GROUP_BASIC report group type. This
type has exactly the classical output format as we know from before
introduction of report groups. However, in addition to that, it allows
to put several reports into a group - this is the very basic grouping
scheme that doesn't change the output format itself:

  Report: report1_name
  Header1  Header2 ...
  value    value   ...
  value    value   ...
  ...      ...     ...

  Report: report2_name
  Header1  Header2 ...
  value    value   ...
  value    value   ...
  ...      ...     ...

libdm: report: implement DM_REPORT_GROUP_SINGLE for a group containing single report only

There's no change in output for this report group type - with this type,
we only make sure there's always only one report in a group at a time,
not more.

libdm: report: introduce dm_report_group

This patch introduces DM report group (represented by dm_report_group
structure) that is used to group several reports to make a whole. As a
whole, all the reports in the group follow the same settings and/or
formatting used on output and it controls that the output is properly
ordered (e.g. the output from different reports is not interleaved
which would break readability and/or syntax of target output format
used for the whole group).

To support this feature, there are 4 new functions:
  - dm_report_group_create
  - dm_report_group_push
  - dm_report_group_pop
  - dm_report_group_destroy

From the naming used (dm_report_group_push/pop), it's clear the reports
are pushed onto a stack. The rule then is that only the report on top
of the stack can be reported (that means calling dm_report_output).
This way we make sure that the output is not interleaved and provides
determinism and control over the output.

Different formats may allow or disallow some of the existing report
flags controlling output itself (DM_REPORT_OUTPUT_*) to be set or not so
once the report is pushed to a group, the grouping code makes sure that
all the reports have compatible flags set and then these flags are
restored once each report is popped from the report group stack.

We also allow to push/pop non-report item in which case such an item
creates a structure (e.g. to put several reports together with any
opening and/or closing lines needed on output which pose as extra
formatting structure besides formatting the reports).

The dm_report_group_push function accepts an argument to pass any
format-specific data needed (e.g. handle, name, structures passed
along while working with reports...).

We can call dm_report_output directly anytime we need (with the only
restriction that we can call dm_report_output only for the report that
is currently on top of the group's stack). Or we don't need to call
dm_report_output explicitly in which case all the reports in a stack are
reported on output automatically once we call dm_report_group_destroy.

vgreduce: fix location of lvmlockd global lock

The lvmlockd global lock was missing the non-repair case,
which caused the new orphan PV created by vgreduce to
not be seen by other hosts.

lvmlockd: fix dropping PVs in rescanning VG

This fixes a problem in commit ae0a8740c.  The problem
in that commit was that all existing PVs are initially
dropped from lvmetad.  This works if the VG is updated
at the end, which replaces the dropped PVs, but if the
rescan finds that the VG seqno is unchanged, it leaves
the cached VG in place.  So, we should only drop the
existing PVs in lvmetad when the VG is going to be updated.

post-release

pre-release

tools: add missing destroy_processing_handle in pvscan and vgreduce code

pvscan: don't activate LVs when use_lvmetad=0

commit 15da467b was meant to address the case where
use_lvmetad=1 in lvm.conf, and lvmetad is not available,
in which case, pvscan --cache -aay should activate LVs.

But the commit unintentionally also changed the case
where use_lvmetad=0 in lvm.conf, in which case
pvscan --cache -aay should not activate LVs, so fix
that here.

pvscan: fix lvmlockd global lock

This should have been removed when pvscan was
recently converted to use process_each_pv which
does the lvmlockd locking.

pvscan: do activation when lvmetad is not running

When pvscan --cache -aay fails to connect to lvmetad it will
simply exit and do nothing.  Change this so that it will
skip the lvmetad cache step and do the activation step from
disk.

lvmlockd: fix rescanning VG

Previously, new PVs that were added to the VG were not scanned.

post-release

pre-release

lvmdbusd: Remove duplicate test code

lvmdbusd: Add test for DataLv & MetaDataLv

Added tests which expose an issue found with these properties.

lvmdbusd: Create correct LV object type

We were initially looking to see if an LV was hidden and if it was we were
creating an instance of a LvCommon object to represent it.  Thus if we
had a hidden cache pool for example we were missing the methods and
properties for the cache pool.  However, when we create the object path,
any hidden LVs, regardless of type/functionality will be placed in the
hidden path.

lvmdbusd: Add method get_object_path_by_lvm_id

The object manager method get_object_by_lvm_id was used in many cases for
the sole reason of getting the object path for the object.  Instead of
retrieving the object and then calling 'dbus_object_path' on the object, we
are adding a method which returns the object path.

lvmdbusd: Rename get_object_path_by_lvm_id

Renaming to get_object_path_by_uuid_lvm_id, to clarify that both the uuid
and the lvm id are required.

lvmdbusd: Change print statement to py3 syntax

lvmdbusd: Bug fix for missing LV properties

When we are processing the LVs we need to build up dbus objects from least
dependent to most dependent, so that we have information available when
constructing.

lvmdbusd: Add data_lv and metadata_lv to cache pool interface

See: https://bugzilla.redhat.com/show_bug.cgi?id=1342558

lvmdbusd: Add roles property to LV common interface

See: https://bugzilla.redhat.com/show_bug.cgi?id=1342559

WHATS_NEW: add recent changes

cleanup: typo in WHATS_NEW_DM

display: yes no prompt improvement

Original code missed to catch all apperances of SIGINT.
Also enhance logging when running in shell without tty.
Accept this regex as valid input:
'^[ ^t]*([Yy]([Ee]([Ss]|)|)|[Nn]([Oo]|))[ ^t]*$'

lvmdump: also collect output from lsblk command when running lvmdump -s

lsblk provides nice and quick overview of the storage/sysfs structure
that is useful for debugging - collect its output when running lvmdump -s.

vgcreate, pvcreate, vgextend: don't use a device with duplicates

If duplicate orphan PVs exist, don't allow one of them to be
used for vgcreate/pvcreate/vgextend.

lvmcache: fix duplicate handling with multiple scans

Some commands scan labels to populate lvmcache multiple
times, i.e. lvmcache_init, scan labels to fill lvmcache,
lvmcache_destroy, then later repeat

Each time labels are scanned, duplicates are detected,
and preferred devices are chosen.  Each time this is done
within a single command, we want to choose the same
preferred devices.  So, check for existing preferences
when choosing preferred devices.

This also fixes a problem with the list of unused duplicate
devs when run in an lvm shell.  The devs had been allocated
from cmd memory, resulting in invalid list entries between
commands.

lvmcache: add optional dev arg to lvmcache_info_from_pvid

A number of places are working on a specific dev when they
call lvmcache_info_from_pvid() to look up an info struct
based on a pvid.  In those cases, pass the dev being used
to lvmcache_info_from_pvid().  When a dev is specified,
lvmcache_info_from_pvid() will verify that the cached
info it's using matches the dev being processed before
returning the info.  Calling code will not mistakenly
get info for the wrong dev when duplicate devs exist.

This confusion was happening when scanning labels when
duplicate devs existed.  label_read for the first dev
would add an info struct to lvmcache for that dev/pvid.
label_read for the second dev would see the pvid in
lvmcache from first dev, and mistakenly conclude that
the label_read from the second dev can be skipped
because it's already been done.  By verifying that the
dev for the cached pvid matches the dev being read,
this mismatch is avoided and the label is actually read
from the second duplicate.

lvmetad: handle update failures

If a command gets stuck during an lvmetad update, lvmetad
will cancel that update after the timeout.  The next command
to check the lvmetad will see that lvmetad needs to be
populated because lvmetad will return token of "none" after
a timed out update (same as when lvmetad is not populated
at all after starting.)

If a command gets an error during an lvmetad update, it
will now just quit and leave its updating token in place.
That update will be cancelled after the timeout.

lvmetad: remove disabled case for "scan error"

Failures while populating lvmetad will be handling
differently in a subsequent commit.

lvmetad: define special update in progress string

blkdeactivate: fix regression in blkdeactivate causing dm and md devices to be skipped.

Commit #5b3a4a9 caused the "name" variable to be cleared if
declaration and assignment is on two lines so put it back
so it's on one line for it to work again.

post-release

pre-release

pvmove: disallow tag args

pvmove began processing tags unintentionally from commit,
6d7dc87cb pvmove: use toollib

pvmove works on a single PV, but tags can match multiple PVs.
If we allowed tags, but processed only the first matching PV,
then the resulting PV would be unpredictable.

Also, the current processing code does not allow us to simply
report an error and do nothing if more than one PV matches the tag,
because the command starts processing PVs as they are found,
so it's too late to do nothing if a second PV matches.

man: fixed typo in lvcreate.8

It's supposed to be "smaller than" instead of "smaller then".

cleanup: compile fixes for --disable-devmapper

Make lvm2 compilable when configured with: --disable-devmapper.

man: lvmconfig: add note about --type diff and --mergedconfig

lvmconfig: fix lvmconfig --type diff to display complete diff if config cascade used

If configuration consists of several sources in config cascade
("config cascade" defined in man lvmconfig(8)), lvmconfig displayed
only difference from defaults of the topmost config in the cascade.
Fix lvmconfig to display complete difference, considering all
the configuration in the cascade.

For example, before this patch:

(use_lvmetad=0 set in lvm.conf which differs from defaults)
$ lvmconfig --type diff
global {
use_lvmetad=0
}

(compact_output=1 set on cmd line)
$ lvmconfig --type diff --config report/compact_output=1
report {
compact_output=1
}

(headings=0 set in profile)
$ lvmconfig --type diff --commandprofile test
report {
headings=0
}

(difference in topmost configuration source is displayed)
$ lvmconfig --type diff --commandprofile test --config report/compact_output=1
report {
compact_output=1
}

With this patch applied (the config cascade is merged before looking for
difference from defaults in configuration):

$ lvmconfig --type diff
global {
use_lvmetad=0
}

$ lvmconfig --type diff --config report/compact_output=1
report {
compact_output=1
}
global {
use_lvmetad=0
}

$ lvmconfig --type diff --profile test
report {
headings=0
}
global {
use_lvmetad=0
}

$ lvmconfig --type diff --profile test --config report/compact_output=1
report {
headings=0
compact_output=1
}
global {
use_lvmetad=0
}

make: add generated parts of lvmdbusd to DISTCLEAN_TARGETS for make distclean

cleanup: use display_name

tests: check losetup -P is correctly handled

Validate pvcreate will not overwrite partitioned loop device.

tests: extend prepare_loop

Treat args after size  as 'extra' params for losetup.

devices: handle partscan loop devices

Treat loop device created with 'losetup -P' as regular
partitioned device - so if it has partition table,
prevent its usage in commands like 'pvcreate'.

Before 'pvcreate /dev/loop0' could have erased and formated as PV,
after this patch, device is filtered out and cannot be used.

coverity: fix warnings about missing return value check for sscanf

All the variables for sscanf in lvmlockctl.c and lvmlockd-sanlock.c are
zeroed before sscanf call so the failure is detected by seeing the zero
value instead of proper one in subsequent code - so use (void) for
sscanf calls to ignore return value here.

coverity: missing check for id_write_format return value

coverity: blkdeactivate: separate format and args for printf and declare and assign separately to avoid masking return values

coverity: fix possible resource leak of descendants_buffer in _print_historical_lv fn

tests: add dmstats to CLEAN_TARGETS for make clean

toollib: properly reset selection handle on selection failure in select_match_{pv,vg,lv}

report: fix lvm devtypes internal error if -S is used with field name from pvs/vgs/lvs

Before this fix, when reporting 'lvm devtypes', the report was
initialized with incorrect reserved values - the ones used for
pvs/vgs/lvs report were used instead of NULL value (because devtypes
doesn't have any reserved values).

For example, trying to (incorrectly) use lv_name for the -S|--select
with lvm devtypes which doesn't have this field at all:

Before this patch (internal error issued):

$ lvm devtypes -S 'lv_name=lvol0'
  Internal error: _check_reserved_values_supported: field-specific reserved value of type 0x0 for field  not supported
  Internal error: dm_report_init_with_selection: trying to register unsupported reserved value type, skipping report selection
  DevType       MaxParts Description
  aoe                 16 ATA over Ethernet
  ataraid             16 ATA Raid
  bcache               1 bcache block device cache
  ...

With this patch applied (correct error displayed about
unrecognized selection field):

$ lvm devtypes -S 'lv_name=lvol0'
  Device Types Fields
  -------------------
    devtype_name           - Name of Device Type exactly as it appears in /proc/devices. [string]
    devtype_max_partitions - Maximum number of partitions. (How many device minor numbers get reserved for each device.) [number]
    devtype_description    - Description of Device Type. [string]

  Special Fields
  --------------
    selected               - Set if item passes selection criteria. [number]
    help                   - Show help. [unselectable number]
    ?                      - Show help. [unselectable number]

  Unrecognised selection field: lv_name
  Selection syntax error at 'lv_name=lvol0'.
  Use 'help' for selection to get more help.

toollib: simplify internal selection calls for non-reporting tools

Some of the variables were set superfluously - we can just use existing
"struct processing_handle" which includes "struct selection_handle".

tests: check thin is not flushed for status

We finally approach a moment where we generally avoid
flushing thin-pool with every lvs command...

snapshot: for invalid snapshot show 100%

Recent commit 92eba53a797a011d1ce6fbd7bef88eab41af2072 started to report
empty "" data usage of invalid snapshot, restore 100% to be shown.

tests: stacked snapshot merge

tests: check cache_mode change on cachepool

debug: use display_lvname

cache: add log_error on error path

Validate and report error when lv_cache_status is called
for inactive LV, or pending delete or unused cache_pool.

report: convert more options to use single status

Convert fields into using a single status ioctl call per LV.
This is a bit tricky since when there are more complicated
stacks, at this moment its undefined which values should be shown.

It's clear we need to cache more then single ioctl per LV,
but also we need to define more explicitely relation between
reported values for snapshots.

This patch is not a final state, rather a transitional step.
It should not be giving more 'worst' values then previous
many-ioctl-calls-per-lv solution.

snapshot: use seg_status for attrs

lv: introduce lvseg_percent_with_info_and_seg_status

Add function to obtain percentage value for cache lv_seg_status.
This API is rather evolving 'middle' step as the ultimate goal
is segment API fuctionality.

But first we need to be clear at reporting level which values
are needed to be reported for which LVs and segments.

lvstatus: enhance seg_status to handle snapshot

Add more code to properly store status for snapshot segment
maintaining lvm2 fiction of COW and snapshot internal volumes.

The key issue here is however not though-through reporting
logic - as there is no single answer for whole line state.
It not counting with layer and we may need few more ioctl to
cover all reporting needs depending upon what is actually
needed.

In reality we need to 'cache' more ioctl status queries for
individual LVs and their segments (so they checked at most once).

The other 'hard' topic for conversion is mirror segment handling.

Also we definitelly need to relocate some logic into segment's methods,
yet it might be complex as we have not clear border between targets.

TODO: define more clearly how are reporting fields defined in case
we 'stack' volumes like   -   cache of stacked  thin LV snapshot origin.

refresh: call resume after failing suspend

lv_refresh_suspend_resume() has escaped with fail ret code
after failing suspend and could have left many volumes in suspend state.

So always unconditionally call resume also  when suspend has failed.

cleanup: drop cmd and constify lv for lv_refresh_suspend_resume()

Like with most other lv_manip* functions take just LV arg and get cmd
from embeded pointer when needed.