This API is the entry point to output modification of the logger. Currently,
everything is done by virLogParseAndDefineOutputs. Parsing and defining will be
split into two operations both handled by this method transparently.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

Abstraction added over parsing a single filter. The method parses potentially a
set of logging filters, while adding each filter logging object to a
caller-provided array.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

Another abstraction added on the top of parsing a single logging output. This
method takes and parses the whole set of outputs, adding each single output
that has already been parsed into a caller-provided array. If the user-supplied
string contained duplicate outputs, only the last occurrence is taken into
account (all the others are removed from the list), so we silently avoid
duplicate logs.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

Same as for outputs, introduce a new method, that is basically the same as
virLogParseAndDefineFilter with the difference that it does not define the
filter. It rather returns a newly created object that needs to be inserted into
a list and then defined separately.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

Introduce a method to parse an individual logging output. The difference
compared to the virLogParseAndDefineOutput is that this method does not define
the output, instead it makes use of the virLogNewOutputTo* methods introduced
in the previous patch and just returns the virLogOutput object that has to be
added to a list of object which then can be defined as a whole via
virLogDefineOutputs. The idea remains still the same - split parsing and
defining of the logging primitives (outputs, filters).
Additionally, since virLogNewOutputTo* methods are now finally used,
ATTRIBUTE_UNUSED can be successfully removed from the methods' definitions,
since that was just to avoid compiler complaints about unused static functions.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

Now that we're in the critical section, syslog connection can be re-opened
by issuing openlog, which is something that cannot be done beforehand, since
syslog keeps its file descriptor private and changing the tag earlier might
introduce a log inconsistency if something went wrong with preparing a new set
of logging outputs in order to replace the existing one.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

Continuing with the effort to split output parsing and defining, these new
functions return a logging object reference instead of defining the output.
Eventually, these functions will replace the existing ones (virLogAddOutputTo*)
which will then be dropped.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

Prepare a method that only defines a set of filters. It takes a list of
filters, preferably created by virLogParseFilters. The original set of filters
is reset and replaced by the new user-provided set of filters.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

Prepare a method that only defines a set of outputs. It takes a list of
outputs, preferably created by virLogParseOutputs. The original set of outputs
is reset and replaced by the new user-provided set of outputs.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

Outputs are a bit trickier than filters, since the user(config)-specified
set of outputs can contain duplicates. That would lead to logging the same
message twice. For compatibility reasons, we cannot just error out and forbid
the daemon to start if we find duplicate outputs which do not make sense.
Instead, we could silently take into account only the last occurrence of the
duplicate output and remove all the previous ones, so that the logger will not
try to use them when it is looping over all of its registered outputs.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

This method allocates a new filter object which it then returns back to caller.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

In order to later split output parsing and output defining, introduce a new
function which will create a new virLogOutput object which the parser will
insert into a list with the list being eventually defined.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

There is really no reason why we could not keep journald's fd within the
journald output object the same way as we do for regular file-based outputs.
By doing this we later won't have to special case the journald-based output
(due to the fd being globally shared) when replacing the existing set of outputs
with a new one. Additionally, by making this change, we don't need the
virLogCloseJournald routine anymore, plain virLogCloseFd will suffice.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

Right now virLogParse* functions are doing both parsing and defining of filters
and outputs which should be two separate operations. Since the naming is
apparently a bit poor this patch renames these functions to
virLogParseAndDefine* which eventually will be replaced by virLogSet*.
Additionally, virLogParse{Filter,Output} will be later (after the split) reused,
so that these functions do exactly what the their name suggests.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

During first stage of virlog.c refactor, commit 0b231195 forgot to remove the
macro definition along with its usage.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

For one VM, it could had more than one graphical display.
Such as we coud add both vnc and spice display to a VM.

This patch introduces '--all' for showing all
possible graphical display of a active VM.
Signed-off-by: NChen Hanxiao <chenhanxiao@gmail.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

If the event is already disabled, then don't bother with setting it
disabled again.  Causes unnecessary error on systems that don't support
the feature anyway.

Make it clearer that the perf event is based/for the host cpu and
use the virPerfEventTypeToString to convert the type to a string

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

Alter the descriptions to match what the cpu_cycles actually is

The intel-iommu device has existed since QEMU 2.2.0, but
it was only possible to create it with -device since
QEMU 2.7.0, thanks to:

  commit 621d983a1f9051f4cfc3f402569b46b77d8449fc
  Author: Marcel Apfelbaum <marcel@redhat.com>
  Date:   Mon Jun 27 18:38:34 2016 +0300

    hw/iommu: enable iommu with -device

    Use the standard '-device intel-iommu' to create the IOMMU device.
    The legacy '-machine,iommu=on' can still be used.

The libvirt capability check & command line formatting code
is thus broken for all QEMU versions 2.2.0 -> 2.6.0 inclusive.

This fixes it to use iommu=on instead.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

This has been announced on the list:

https://www.redhat.com/archives/libvir-list/2016-October/msg00187.htmlSigned-off-by: NMarko Myllynen <myllynen@redhat.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Commit 660468b1 forgot to add it, so let's add it now to prevent future linker
issues.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

This was needed for RHEL 4 vintage distributions, which we
haven't supported for a long time now.

Running the output of qemu -help doesn't make any sense.  We should be
looking for libvirt being mentioned in the output.  This worked by
accident, let's make it work as expected it to.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

This file requires three steps instead of two.
Move it earlier in the list of targets to avoid waiting for it.

Remove DOC_SOURCE_DIR, introduced by and
unused since commit b325d741.

PERL is already detected in configure.ac.

Since introduction of chardev hotplug the code was wrong for the UDP
case and basically created a TCP socket instead. Use proper objects and
type for UDP.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1377602

Until now the test was rather useless since it didn't check the
arguments formatted and didn't use properly configured chardev objects.

Add the expected arguments and instrument the test to validate them.
Modify some test cases to actually add valid data.

Note that the UDP test data is currently wrong due to a bug.

The chardev attach test would do all the tests in one virTestRun
instance. If one sub-test failed then the test would report failure
improperly and the error would be hard to debug since the error pointer
was overwritten.

Add code that takes a string and matches it against the data passed as
arguments from qemu. This is a simpler version of
qemuMonitorTestAddItemParams.

Use much simpler logic to determine parts of the code to print.

Rather than copy-paste - use a macro

Unfortunately due to how the RNG schema was written keeping the 'value'
and 'value'_max next to each other in the XML causes a schema failure,
so the FORMAT has to write out singly rather than optimizing to write
out both values at once
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

We're about to add more options, let's avoid having multiple if-then-else
which each try to set up the qemuMonitorJSONMakeCommand call with all the
parameters it knows about.

Instead, use the fact that when a NULL is found in the argument list that
processing of the remaining arguments stops and just have call.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

We're about to add 6 new options and it appears (from testing) one cannot
utilize both the shorthand (alias) and (much) longer names for the arguments.
So modify the command builder to use the longer name and of course alter the
test output .args to have the similarly innocuous long name.

Also utilize a macro to build that name makes it so much more visually
appealing and saves a few characters or potential cut-n-paste issues.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

It was missing... Also since I'm using the soft link from qemuxml2xmloutdata
to the qemuxml2argvdata file, modify the output file to have the necessary
<address> elements plus the mouse and keyboard.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

The upstream qemu commit 'dce13204' changed the wording just slightly
to add 'in bursts' essentially.  Just following that model here.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Change Marco to Macro
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

When I added support for the pcie-expander-bus controller in commit
bc07251f, I incorrectly thought that it only had a single slot
available. Actually it has 32 slots, just like the root complex aka
pcie-root (the part that I *did* get correct is that unlike pcie-root
a pcie-expander-bus doesn't allow any integrated endpoint devices -
only pcie-root-ports and dmi-to-pci-controllers are allowed).

GCC complained that

vsh.c: In function 'vshReadlineOptionsGenerator':
vsh.c:2622:29: warning: unused variable 'opt' [-Wunused-variable]
         const vshCmdOptDef *opt = &cmd->opts[list_index];
                             ^
vsh.c: In function 'vshReadlineParse':
vsh.c:2830:44: warning: 'opt' may be used uninitialized in this function
[-Wmaybe-uninitialized]
             completed_list = opt->completer(autoCompleteOpaque,
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>