Add the functions to add/remove elements from the hashed secret obj list.
These will replace secret_driver functions secretAssignDef and secretObjRemove.

The virSecretObjListAddLocked will perform the necessary lookups and
decide whether to replace an existing hash entry or create a new one.
This includes setting up the configPath and base64Path as well as being
able to support the caller's need to restore from a previous definition
in case something goes wrong in the caller.

Move the driver specific secretUsageIDForDef into secret_conf.c. It could
be more of a general purpose API.

New API's including unlocked and Locked versions in order to be able
to use in either manner.

Support for searching hash object lists instead of linked lists will
replace existing secret_driver functions secretFindByUUID and
secretFindByUsage

Move virSecretObj from secret_driver.c to virsecretobj.h

To support being able to create a hashed secrets list, move the
virSecretObj to virsecretobj.h so that the code can at least find
the definition.

This should be a temporary situation while the virsecretobj.c code
is patched in order to support a hashed secret object while still
having the linked list support in secret_driver.c. Eventually, the
goal is to move the virSecretObj into virsecretobj.c, although it
is notable that the existing model from which virSecretObj was
derived has virDomainObj in src/conf/domain_conf.h and virNetworkObj
in src/conf/network_conf.h, so virSecretObj wouldn't be unique if
it were to remain in virsecretobj.h  Still adding accessors to fetch
and store hashed object data will be the end goal.

Add definitions and infrastucture in virsecretobj.c to create and
handle a hashed virSecretObj and virSecretObjList including the class,
object, lock setup, and disposal API's. Nothing will call these yet.

This infrastructure will replace the forward linked list logic
within the secret_driver, eventually.

Our distcheck is broken. Well, it works but only by pure chance.
When wireshark plugin is enabled, we try to query which path
should the plugin be installed into. Firstly, we try to ask
pkg-config as some releases of wireshark already sets
corresponding variable in their pkg-config files. However, if we
obtained no value from there we try to construct the path on our
own. Based on our observations it usually is:
$libdir/wireshark/plugins/$version/.
Now, the problem is in the way we are deciding whether we have
obtained the plugin directory from pkg-config or not. Simply
said, we are checking wrong variable. The variable we are
checking has never been set, thus in our test is empty and
therefore we will always construct the plugin dir path on our
own, regardless of its presence in the pkg-config file.
To make things worse, after fixing this problem, VPATH build was
broken as it now tried to install plugin into correct directory.
Yes, this is problem, because --prefix was not honoured and
everything but the plugin was installed into given prefix. I've
managed to resolve this issue by replacing plugin dir prefix with
our own. So when doing regular installation (our prefix ==
wireshark prefix), nothing changes. When doing VPATH build &
installation plugin is installed into correctly prefixed dir.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

We do have something similar for installing init system files.
Basically I'm trying to avoid the following warning produced by
automake:

tools/Makefile.am:429: warning: uninstall-local was already defined in condition TRUE, which includes condition WITH_BSD_NSS ...
tools/Makefile.am:292: ... 'uninstall-local' previously defined here
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

This target has been disabled historically for whatever reason.
Now that we do uninstall properly enable the test again.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

This function - in contrast with qemuBuildCommandLine - merely
constructs our internal command representation of a domain. This
is then later compared against expected output. Or, this function
is used also in virConnectDomainXMLToNative(). But due to a copy
paste error this function, just like its image - has @forceFips
argument that if enabled forces FIPS, otherwise mimics FIPS state
in the host. If FIPS is enabled or forced the generated command
line is different to state in which FIPS is disabled. Problem is,
while this could be desired in the virConnectDomainXMLToNative()
case, this is undesirable in the test suite as it will produce
unpredicted results.
Solution to this is to rename argument to @enableFips to
specifically tell whether we expect command line to be build in
either of fashions and make virConnectDomainXMLToNative()
implementation fetch FIPS state and pass it to
qemuProcessCreatePretendCmd().
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

This error message was too specific, based on the incorrect assumption
that any error was cause by auto-added bridges:

  failed to create PCI bridge on bus 2: too many devices
  with fixed addresses

In practice you can't know if a bridge with an index <= the bus it's
connecting to was added automatically, or if it was a mistake in
explicit config, and the auto-add problem is going to be dealt with in
a different way in an upcoming patch. The new message is this:

  PCI Controller at index 1 (0x01) has "
  bus='0x02', but bus must be <= index

(note that index is given in both decimal and hex because it is
formatted as decimal in the XML, but bus is formatted as hex, and
displaying the hex value of index makes it easier to see the problem
when index > 9 (which will often be the case with PCIe, since most
controllers only have a single port, not 32 slots as with standard
PCI)).

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

Use L<> instead of C<> for URLs and man pages.

Format the text properly.

podchecker(1) complained about these, eg.

  *** WARNING: Verbatim paragraph in NAME section at line 3 in
               file tools/virt-host-validate.pod

No need to special-case this one: we can add it to EXTRA_DIST so
that it will be shipped in any case, and if WITH_LOGIN_SHELL
happens to be enabled we mark it for installation as well.

We can't use eg. @sysconfdir@ directly in the .pod file, because
pod2man(1) will interpret that as a variable name and format it
accordingly.

Instead, we use eg. SYSCONFDIR and use a subsequent sed(1) call
to turn it into the expected @sysconfdir@.

All $(MANINFILES) should be deleted on distclean.

Define $(PODFILES) and $(MANINFILES) so that adding a new man
page only requires changes in a few, well defined spots.

The generated man pages may contain information that depend on
the build configuration, so they should not be shipped but
rather always built on the user's machine.

After this commit, all man pages are generated using the same two
steps:

  1. Process a source $command.pod file with pod2man(1) to obtain
     a valid man page in $command.$section.in

  2. Process $command.$section.in with sed(1) to obtain the final
     man page in $command.$section

Man pages in daemon/ and src/ are being already subjected to this
post-processing step: make it so those in tools/ are as well.

No file should be created inside $(srcdir) during build.

Instead of embedding the pod information inside the respective
source files, store them in separate files.

This allows us to reduce the number of custom build rules as
most of the information can be inferred for the file name;
moreover, text editors are more likely to use proper syntax
highlighting for standalone pod files.

This is the source file for the virt-admin(1) manual page, so
it should be shipped.

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

QEMU_BLOCK_IOTUNE_MAX is the maximum inclusively, so let's modify the
message so it makes sense.

https://bugzilla.redhat.com/show_bug.cgi?id=1329041Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

When describing attributes and elements, we mostly stick to
a certain pattern; however, there are a few cases when the
information is not presented in the usual way.

Since there doesn't seem to be any reason not to follow the
tried and true formula, rework those bits to fit the rest of
the documentation.

Commit 61b070cf cleaned up a number of cases where the <dt>
element was used to document symbols, but the symbol itself was
not inside a <code> element.

To make sure we don't end up having to clean up again a few
months from now, introduce a syntax-check rule that can spot
such mistakes.

All existing exceptions are marked as such, with either file
or line granularity depending on the case.

libvirt-common.h is generated into builddir/include/libvirt. apibuild.py
only operated on srcdir/inlcude/libvirt. With VPATH build
srcdir/docs/libvirt-libvirt-common.html would not get generated and make
RPM failed.

This unifies the test scripts to all use the similar pattern added for
schematests in ace4aecd. This gives the following

- Enables running all tests from outside of tests/ dir
- Drops redundant abs_* definitions, which are set by test-lib.sh
- Drops unnecessary srcdir variable which was only used for sourcing
    test-lib.sh

Behavior changes:

- srcdir can no longer be overwritten, but I don't know why anyone would
    really need to...
- Script VERBOSE setting no longer prints commands executed by test-lib.sh.
    if anyone cares I suggest handling this in test-lib.sh which already
    has other verbose style handling

We presently don't give any indication if the VirtualBox version
isn't in our support whitelist.

These old tests expect to run against a real xen connection via
xend running on the host. Our intentions for the test suite are
that it doesn't require interacting with any specific host resources,
so these don't really belong here.

This finishes the job started by commit 81f3839f - removing the
erroneous reference to nonexistent "igmp-ipv6" protocol.

Add bolding for <dt><code> elements to make them "stick out" on the
page rather that just a stream of text where the elements only differ
by slightly different font style.

Most of the time, the <dt> tag is used when providing
documentation for a symbol; enclose symbols in <code> tags to
style them appropriately.

Ancient python didn't like the new list added in 99283874. Convert it to
a dict.

The values are currently limited to LLONG_MAX which causes some
problems.  QEMU conveniently changed their maximum to 1e15 (1 PB) which
is enough for some time and we need to adapt to that so that we don't
throw "Unknown error" messages.  Strictly limiting these values actually
fixes some corner case values (off-by-one checks in QEMU probably).

Since values out of the new specified range do not overflow anything,
change the type of error as well.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1317531Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

And confdata to virconfdata, since 'conf' can mean a few different
things in libvirt

Store the test list in libvirtd_test_scripts, and use it where
appropriate. This also fixes the fact that we didn't ship
virsh-uriprecedence when libvirtd build is disabled.

$ echo -n 'log_level=1' > ~/.config/libvirt/libvirtd.conf
$ libvirtd --timeout=10
2014-10-10 10:30:56.394+0000: 6626: info : libvirt version: 1.1.3.6, package: 1.fc20 (Fedora Project, 2014-09-08-17:50:42, buildvm-05.phx2.fedoraproject.org)
2014-10-10 10:30:56.394+0000: 6626: error : main:1261 : Can't load config file: configuration file syntax error: /home/rjones/.config/libvirt/libvirtd.conf:1: expecting a value: /home/rjones/.config/libvirt/libvirtd.conf

Rather than try to fix this in the depths of the parser, just catch
the case when a config file doesn't end in a newline, and manually
append a newline to the content before parsing

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

IGMP is used on IPv4 networks tp setup multicast group memberships. On
IPv6, this job is done by Multicast Listener Discovery (MLD), which
uses ICMPv6 packets rather than its own IP protocol number like IGMP.

The nwfilter documentation lists "igmp-ipv6" as one of the possible
protocols, but this is ignored (and stripped from the xml). This patch
removes that erroneous reference.

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