The log filters have supported the use of a "+" before the source match
string to request that a stack trace be emitted for every log message:

  commit 54856395
  Author: Daniel P. Berrange <berrange@redhat.com>
  Date:   Wed May 9 15:18:56 2012 +0100

    Allow stack traces to be included with log messages

    Sometimes it is useful to see the callpath for log messages.
    This change enhances the log filter syntax so that stack traces
    can be show by setting '1:+NAME' instead of '1:NAME'.

With the huge & ever increasing number of logging statements per file,
this will be incredibly verbose and have a major performance penalty.
This makes the feature impractical to use widely and as such it is not
worth the code maint cost.

Removing this seldom used feature allows us to drop the 'execinfo'
module in gnulib which provides the backtrace() function which doesn't
exist on non-Linux.

Users who want to get stack traces of parts of libvirt can use GDB,
or systemtap for live tracing with minimal perf impact.
Reviewed-by: NJán Tomko <jtomko@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Strongly recommend against use of the log_levels setting since it
creates overly verbose logs and has a serious performance impact.

Describe the log filter syntax better and mention use of shell
glob syntax. Also provide more realistic example of good settings
to use. The libvirtd example is biased towards QEMU, but when the
drivers split off each daemon can get its own more appropriate
example.
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Most of the augeas test files use ::CONFIG:: to pull in the master
config file for testing. This ensures that entries added to the config
file are actually tested by augeas.

This identified the missing admin_max_clients example in the virtlogd
config file, which in turn prompted a change in description of the
max_clients parameter, since these daemons don't have separate
readonly & readwrite sockets.
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

The global log buffer feature was deleted in:

  commit c0c8c1d7
  Author: Daniel P. Berrange <berrange@redhat.com>
  Date:   Mon Mar 3 14:54:33 2014 +0000

    Remove global log buffer feature entirely

    A earlier commit changed the global log buffer so that it only
    records messages that are explicitly requested via the log
    filters setting. This removes the performance burden, and
    improves the signal/noise ratio for messages in the global
    buffer. At the same time though, it is somewhat pointless, since
    all the recorded log messages are already going to be sent to an
    explicit log output like syslog, stderr or the journal. The
    global log buffer is thus just duplicating this data on stderr
    upon crash.

    The log_buffer_size config parameter is left in the augeas
    lens to prevent breakage for users on upgrade. It is however
    completely ignored hereafter.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

This was in the 1.2.3 release, and 4 years is sufficient time for a
graceful upgrade path for augeas, so all remaining traces are now
removed.
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Add a virtlockd-admin-sock can serves the admin protocol for the virtlockd
daemon and define a virtlockd:///{system,session}  URI scheme for
connecting to it.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

A earlier commit changed the global log buffer so that it only
records messages that are explicitly requested via the log
filters setting. This removes the performance burden, and
improves the signal/noise ratio for messages in the global
buffer. At the same time though, it is somewhat pointless, since
all the recorded log messages are already going to be sent to an
explicit log output like syslog, stderr or the journal. The
global log buffer is thus just duplicating this data on stderr
upon crash.

The log_buffer_size config parameter is left in the augeas
lens to prevent breakage for users on upgrade. It is however
completely ignored hereafter.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Each new VM requires a new connection from libvirtd to virtlockd.
The default max clients limit in virtlockd of 20 is thus woefully
insufficient. virtlockd sockets are only accessible to matching
users, so there is no security need for such a tight limit. Make
it configurable and default to 1024.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The virtlockd daemon supports an /etc/libvirt/virtlockd.conf
config file, but we never installed a default config, nor
created any augeas scripts. This change addresses that omission.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>